Cart
[Home] [By Thread] [By Date] [Recent Entries]
* Sean Mc Grath | | For me, I favour the XML side of the lever. Any declarative syntax | has its limits. It has been my experience that the limits of SGML's | declarative syntax are quickly reached.[1] Any SGML system I have | ever worked on has a large collection of ancilliary software to | perform validation, data aggregation, authoring short-cuts that are | not possible with pure SGML syntax. I tend to favour the XML side myself (unless I have to write the documents manually), and I think most people will do so. To me, XML and SGML are a perfect example of what happens when the worse-is-better and the-right-thing philosophies collide. (Even though SGML doesn't really qualify as the-right-thing.) The main problem with SGML is the complexity of the syntax, which means that you need a large and complex application to get hold of your data, and as Gabriel prophesied this means that you have few choices of applications. For XML we are beginning to see what we never saw with SGML: a plethora of pluggable processing components. Much of this is due to SAX, I think, but much is also due to the simpler nature of XML syntax. I'm pretty sure that SAX2 will only reinforce this trend by making it easier to develop and plug together parser filters and other such components. Better design of XSL processors to allow the introduction of SAX components at various points (of which 4XSL seems to be a good example) would also help. Likewise with toolkits like SAXON. In fact, the only downside is that most of this is happening in a language as awkward as Java. --Lars M. 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/ and on CD-ROM/ISBN 981-02-3594-1 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...)
|
