XML complexity, namespaces (was WG)

[David Megginson]

In his message, in a part that I'm not quoting (I do respond to
specific details below), Marcelo Cantos argues that it's not for us to
decide whether both full SGML and XML can co-exist, and I agree -- I
am simply predicting that the market might not find it worthwhile to
continue developing two standards that are architecturally identical
and differ even in the implementation details only in nit-picky ways.

Choose an arbitrary number for the cost of containing to develop two
standards rather than one -- say, US$100M/year (if all of the big
enterprise vendors have to develop, test, debug, document, support,
and maintain both full SGML and XML versions of their software, as
well as donate employees' time to committee work) and unaccountable
additional hours of free time donated by OSS writers.

Do SGML-specific features like SHORTREFs, data attributes, and
omissible tags sometimes make life simpler for implementors?  Of
course they do.

Are the differences worth US$100M/year (or whatever number you pick)?
I don't know, and the decision is not ours to make, but the market
will figure it out soon enough.  Whatever happens, there will
certainly be money to be made from supporting the existing SGML
installations, so there will be good justification for
backwards-compatibility in some major tools.

Now, on to the specific points...


Marcelo Cantos writes:

 > > 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).

There are work-arounds that you could have used in SGML, such as
synthesised DTDs using ANY.  Both SGML and XML *can* do this, but in
your case, XML makes it a little easier (as would WebSGML).  The
differences are important to us, as SGML/XML implementors, but would
not really concern the architect of a large system except to the point 
that they affected maintainability.

 > > 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!

Or you could simply have defined a round-trip mapping -- tab-delimited 
fields map to <item> elements map back to tab-delimited fields.  You
could also, with XML or SGML, point into the original without altering 
it (HyTime provides good mechanisms for doing that in SGML or XML).

Again, however, Marcello is writing about implementation details, not
about what SGML and XML are capable of representing in the abstract.
In this case, SGML makes life a little easier for a *very* experienced
designer under high-specialised circumstances.

Lexically, SGML and XML differ in minor ways; logically, they are
essentially identical.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)