xml-dev - Re: XML & SGML

["W. Eliot Kimber" <eliot@isogen.com>]

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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)