Cart
[Home] [By Thread] [By Date] [Recent Entries]
Yes. I am *NOT* criticising XML WG choices in the 1990s or 2000s. And I think the change resistant approach was a good tactic for the first decade, but increasingly toxic to the health of standard generalised extensible markup languages subsequently. But we are now past the 2010s even. But I believe that 99% of the people who need general entities just need the (full) standard entities, because without them you need to know a keyboard input mechanism (to write the document) and the appropriate fonts installed (to see the direct character). But most Western users have no idea that input methods are even a thing, nor the idea that not all fonts still cover all the glyphs for the relevant Unicode banks. Only if it provided the standard entity references (ie as built-in undeclared entities mapped to Unicode.) could XML feasibly get rid of the general entity mechanism and still be useful for documents. And only by providing such an alternative could XML extract out instances and DTDs as orthogonal languages. (I mean, in reality DTDs would then die out in favour of better alternatives, I expect. But at its own pace.) (So the question for entities is not "what things can we carve off from XML by denying classic use-cases?" but "can we provide substantially the same capability with substantially lower overhead?") Standard character references are one thing not suitable to be web resources with a URL, any more than individual characters. (Surely no-one regards each character in a URL as itself being a one character shortcut to some web resources for that character?...) But other use-cases for general entities belong as web resources: links and PIs. The entity concept is otiose. We only need standard direct characters, standard named character references and standard numeric character references, built in at language level. (The other advantage of default standard entities only is that they can all be expanded in-place by a parser, removing one of the three issues blamed for preventing optimized performance: too much/complex buffer/object allocation. The other two are all the different encodings supported (does anyone think an XML evolution still needs that kind of on-ramp?) and modal parsing where you need too much context to figure out how to parse from some arbitrary point (to allow parallel parsing). Cheers Rick On Thu, 30 Dec 2021, 1:58 am MURATA, <eb2mmrt@g...> wrote:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
