XML complexity, namespaces (was WG)

[Marcelo Cantos]

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