Re: XML & SGML
At 11:26 AM 5/6/98 -0700, Tim Bray wrote: >At 01:10 PM 5/6/98 -0500, W. Eliot Kimber wrote: >>>>> >He also makes a clear distinction between use domains that require full strength SGML (and can therefore afford to implement its use) and use domains that do not. This is a key message: >XML->full SGML represents a continuum of cost/value that you can choose any point along. ><<<< >The only problem being that we lack the industrial experience >that would tell us at what point XML runs out of steam and you >need SGML extras. I must say, that is one of the #1 questions >I get at customer sites, and I just don't have a good answer >yet. It's not easy; just because they're totally web-oriented >doesn't mean they don't need SGML, and just because they're >currently using the &-connector doesn't mean they couldn't >succeed with just XML. -Tim I say start with XML by itself and see how far you get--that's one of the benefits of XML being SGML--you can slide along the continuum at will at minimal cost. By the time you get a pilot project in place, you'll probably know. The main determiners seem to be: 1. How complex are my DTD development and maintenance requirements? XML DTDs are essentially unmaintainable because of the limitations on the use of parameter entities. This means you either use some non-DTD syntax (e.g., your favorate schema scheme) and generate XML declaration sets as needed or use normal SGML and generate XML documents as needed. The latter is easier to do quickly because there are free tools to do most or all of the work (e.g., SX, etc.). The former might be a better solution in the long term because you can do more clever things. 2. What are my authoring requirements? If you need authoring beyond text editing, your only real choices today are SGML editors with XML support (e.g., ADEPT*Editor's save as XML feature). But even here, most tools should be able to handle XML directly (possibly with a little fiddling). If you need text-based authoring that depends on markup minimization, and such use environments do exist, then you have no choice but to author in SGML and generate XML. Downstream processes (transforms, production) are largely insensitive to the use of XML or SGML because they are not dependent on syntax details but on information semantic (element types rather than omitted start tags). This analysis does not address application issues like the use of XLink, XPointers and XSL. In general, XPointers are not useful for authoring because they are too rigid and lack any form of indirection. XSL is of course not yet defined to the point where you would be safe using it in production. As rule, the XML add-on standards are designed for Web-based delivery only and do not meet the requirements of authoring and archiving. This is because authoring and archiving impose requirements that delivery either does not impose or cannot tolerate (such as indirection or dependence on arbitrary queries for indirection). Fortunately, all of the SGML add-on standards can be applied to XML documents as well as to full-SGML documents, so you can mix and match as you need to. Cheers, Eliot -- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 95202. 214.953.0004 www.isogen.com </Address> 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