Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Mon, Mar 22, 1999 at 08:45:53PM -0500, David Megginson wrote: > Marcus Carr writes: > > > There is what I believe to be a misconception amonst some portions > > of the XML community that XML and SGML are locked in some sort of > > competition, but I don't see any of the same feeling from the SGML > > community. The conclusion that I draw from this is that there is > > some sort of insecurity, perhaps due to the fact that XML feels > > that it must replace SGML in order to ensure its survival. The > > SGML community sees XML as a great boon - a truly sweet way of > > using the data and realising the long-term effort that they have > > put into their datasets. > > XML does nothing that SGML cannot do. When developing the TOC management system for our document fragmenting toolkit, we chose XML to represent the TOC. SGML was not an option, because we didn't know the content model in advance and couldn't build it automatically from the DTD's of the individual documents. Also, we couldn't use a homogeneous element tree with attributes, because we actually extracted structured content from the documents for insertion into the TOC (sure, we could have serialised the content into an SGML attribute, but that would have a been perverse and painful alternative to simply using XML). > SGML does nothing that XML cannot do. On several occasions I have had to import textual information, and have been able treat the data as SGML with appropriate choice of shortrefs. With XML I would have been forced to write an intermediate translation layer and would have consequently lost the originals (or been forced to store the original and transformed document, or add the extra layer to every access). True, they are not always adequate for the job, but I certainly would not have happily forgone them in my project because they wouldn't have been useful in someone else's project! > There are some differences in the ways that XML and SGML accomplish > the same thing, but those differences are trival and unimportant from > an architectural perspective. Whether the differences are trivial is a matter for the requirements spec. to decide, rather than something you can decree in a priori fashion. There will often be cases where such "trivial" differences can have a profound impact on the cost and complexity of a project. > XML benefited from (at the time) 12 years of SGML industry experience > by eliminating a lot of original SGML features (such as the ability to > vary the delimiter set or to omit tags) that turned out to be > obfuscatory design mistakes. I couldn't disagree more, for all the above reasons. One man's design mistakes are another man's salvation. > SGML benefits from 13 years of industry experience in the form of a > small base of stable, production-quality COTS and OSS. > > The question, however, is whether there is a real benefit to > supporting two slightly-variant standards that, in the view of a > system architect, accomplish exactly the same thing in pretty much the > same way. If they did, there might be an issue to resolve. But they don't, so there isn't. Both will continue to be used and developed, and this is as it should be. Cheers, Marcelo -- http://www.simdb.com/~marcelo/ 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...)
|
