XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] It's too late to improve XML ... lessons learned?

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@gmail.com> wrote:
I was a latecomer in the XML WG, but here are my two cents.

Delaying the release of XML 1.0 might have made it more 
complicated since there were very many requests for minor 
extensions. 

Some features of XML (most notably XML entities) could have 
been removed from XML 1.0.  But I do not think that entities 
(with the exception of internal parsed entities) have caused 
significant problems.  Moreover, the SGML camp would have 
rejected XML if entities had been removed from XML.

In his Turing award lecture (1980), Tony Hoare wrote:

When any new language design project is nearing completion, 
there is always a mad rush to get new features added before 
standardization. The rush is mad indeed, because it leads into 
a trap from which there is no escape. A feature which is omitted 
can always be added later, when its design and its implications 
are well understood. A feature which is included before it is fully 
understood can never be removed later.
   
Regards,
Makoto


2021年12月29日(水) 2:44 Roger L Costello <costello@mitre.org>:
Michael Kay wrote:

> we've learnt as a community that trying to improve XML
> doesn't work: the standard is too deeply embedded.

Yes, I can see that. On this very list there have been several attempts to improve XML and none of the attempts gained much traction.

So what is the lesson to be learned from this? How about this:

        When creating a new standard, get it right in its
        first version because if the standard is a success
        you likely won't get a chance to improve it later on.

Is that the lesson to be learned? If so, how to ensure that you "get it right"? For instance, what could the XML Working Group have done differently to get it right? Should the XML Working Group have delayed the release of the XML standard for a year or two until a sizeable group of people had had the opportunity to work with XML and report on its warts?

/Roger

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



--
 --
慶應義塾大学政策・メディア研究科特任教授
村田 真


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS