Cart
[Home] [By Thread] [By Date] [Recent Entries]
This is an interesting thread. Many non-tag-minimization reliables can be put forth as things that SGML "can do" that XML cannot. Things like data attributes, exclusion exceptions, internal SDATA entities and so on. I see SGML and XML at opposite ends of a balanced lever. On one side we have SGML - high on declarative syntax, low on home grown code. On the other side we have XML - low on declarative syntax, high on home grown code. SGML gives you declarative syntax that can obviate the need for coding around certain types of data modelling, content authoring problems. XML is light on the declarative syntax, leaving more in the realm of "application specific" implementation in a programming language. Ultimately, both views have their place and both may be "correct" for a given problem domain. 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. XML fills a nice 80/20 niche here. 20% of SGML's declarative syntax is used 80% of the time. XML draws a line in the sand saying "here is the most useful 80% in an allround cheaper package. You will need to write processing software on top of this but hey!. You would need to do that with SGML anyway." Analogies abound. What does it mean to say you have your data in third normal form in a relational database? It means that you have a base data model that is interchangeable amongst relational database systems. *But* and it is a big *but*. The rest of the stuff that makes up the solution is in some application specific 4GL. <stance slant="pragmatic"> Declarative syntax does not put bread on my table. Solutions to business problems using the beautiful ideas of SGML puts bread on my table. XML gives me a nice package that gives me most of what I want in terms of a robust, simple, implementation of the SGML philosophy. I will build software around this package all day long without ever once missing an SGML feature. Whats more, I'll do it in an open, standardized, cheap programming language that gets the job done fast.[2] When I go under the bus, I believe my customers are in a better state than they would have been if I'd pulled every obscure SGML declarative syntax trick in the book. </stance> [1] Notations are for me, the classic example of the limitations of a declarative syntax and how a declarative syntax feature can subtly fool you into thinking you have solved a problem when all you have done is defer it. You hit, say, a data validation problem that cannot be solved with SGML syntax alone so you invent a notation for it. Knock up the declarative syntax for it. Lovely. It all parses. *However* the declarative syntax does not do anything. You still need to implement it as a processing layer above SGML. [2] Python http://www.python.org <Sean uri="http://www.digitome.com/sean.htm"/> 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...)
|
