Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Must XML be SGML compatible?
 Sorry for posting another mail on this topic to this list, this posting would be more at home in XML.advocacy if there were such a thing... Jarle Stabell wrote: > * The ability of using non-XML-aware SGML tools on XML documents. > > How long will this benefit be of any substantial value? David Megginson writes: <<<< That's hard to say. There is an enormous number of SGML document systems now in place, and (as we know now with the Y2K pseudo-crisis) companies are _very_ reluctant to change their software once they've installed a new system, especially if the system is the result of an expensive and difficult project. >>>> [JS] Then I'd say that they should stick with SGML, then they won't be bothered by XML not being SGML compatible and don't have anything to win with switching to XML if not for using better tools. (Their SGML documents are likely not well-formed XML documents in the first place) > [JS] One of the benefits may be that parsing XML documents will run noticeably > faster with a XML-specfic parser than a general SGML parser. <<<< I don't know enough about automata theory to know if this statement is true (or even verifiable) -- it seems to me, though, that the number of productions in the grammar shouldn't affect parsing speed, and I do know that SGML is designed explicitly to avoid backtracking by requiring no more than one look-ahead token (to everyone's annoyance). >>>> [JS] I don't know the theory well enough to tell how the grammar size influences the speed of the parsers buildt with (LA)LR[1] tools myself, but I guess the typical XML parser won't be buildt by such tools at all, because an XML parser probably is quite simple to build "manually", and because one generally gets faster parsers this way. (Hopefully some of the implementors read this, they could easily falsify my view) I haven't checked all the public XML parsers, I see NXP use JavaCC which is a parser generator, but not a typical Yacc/Bison sort of thing. I would be *very* suprised if someone were able to write a general SGML parser being as fast as the fastest XML parser (in f.i. 3 years time). You also state "to everyone's annoyance". This is exactly what I mean, is the SGML compatibility so much worth that we instead will force upon perhaps millions of users in the next 10-20 years syntactic design "flaws" which are well known to us today? <<<< 1) Credibility: by tying itself to a well-established international standard (ISO 8879), XML can win over conservative users in important areas like financial services and EDI. >>>> [JS] Yes. But I'm not old/wise enough to understand that doing some minor syntactic "fixes" should scare those away as long as it will be an international standard with the great ideas of SGML intact. <<<< 2) Implementation: the XML standard will live and die partly based on the enthusiasm of early implementors; piggy-backing on SGML gives it a good, experienced implementor-base right from the start. >>>> [JS] Yes. But to speak for one possible implementor (myself), I would be much more enthusiastic about it if I believed it was as well-designed as it could be. I really believe in the "semantic" beauty of SGML, the tree structure/groves, the separation between document type and instance, DSSL/XSL etc and also the "general" concrete syntax, but I also think the general user would be better off if XML were *simplified* SGML, not only a well-defined subset/fragment of it. Paul Prescod wrote: <<<< The language that we use to encode humanity's knowledge should be a true standard and not merely a "recommendation." That means that it should be built upon our democratic institutions and not vendor consortiums. >>>> [JS] Agree (with your whole mail). But why must we be so "selfish" to let humanity struggle with SGML compatibility? (No reply necessary... :-) ) As current SGML (and HTML) documents typically won't be well-formed XML documents, I just can't see the big practical win in ensuring that well-formed XML documents should be SGML documents. What I feel *would* have practical value would be SGML documents being wf XML documents, and/or HTML documents being wf XML documents, but none of these will of course be true. Cheers, Jarle ---- "Syntax is arbitrary" [some french linguist or philosopher which name I can't remember the spelling of] xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
