OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] SGML->XML->? (was Re: [xml-dev] SML: Second Try)

[ Lists Home | Date Index | Thread Index ]

Dave Pawson asks:

>Which ones are wrong today?
>What's missing?
>Were the goals too broad?
>Or have they been interpreted too many times in too many different ways?
>Is No. 3 out of date?

>The design goals for XML are:

They aren't wrong; they were optimistic.  I numbered these 
to make this easier to discuss:

    1 XML shall be straightforwardly usable over the Internet.

Sounds good.  Tends to be interpreted in light of item 2.  
Note that nowhere does it say that the HTML design shall 
inform XML.  But it did anyway.  Still, no one blames HTML 
for that.

    2 XML shall support a wide variety of applications.

This seems to be where the row starts.  When originally 
stated, I'm not sure people knew just how broad the 
applications and therefore the application requirements 
would be. SGML tended to be restricted to documents, and 
even though lots of other applications from EDI messaging 
to AI databases were conceived of, those that suggested 
them were lunatic-fringe (a Navy wonk's term for the 
hypertext experts).

    3 XML shall be compatible with SGML.

I don't think it hurt.  Most of us had already learned 
to subset SGML sensibly even when told it violated the 
spirit of standardization.  Spirits don't matter if they 
stay out of the machine.

Today it represents a procedural problem with keeping 
the W3C and ISO aligned.  I believe SGML itself should
be brought up to date but the XML juggernaut takes the 
wind out of that sail; so, it doesn't matter.  It does 
create an opportunity to deprive the future of options. 
SGML flexibility may be something to keep around for that 
time when a new and different system comes to town.

    4 It shall be easy to write programs which process XML documents.

It was a lie then; it's a lie now.  It is never 'easy'.  
It varies by application.  On the other hand, programs 
which made it easier to process XML did come about just 
as they did for SGML.  Revolution and enthusiasm are 
good until they become standard.

    5 The number of optional features in XML is to be kept to the absolute 
      minimum, ideally zero.

This depends on programmers doing as the SGML programmers did: 
figure it out and specify only the features they need.  However, 
if a core component (say parser) is the performance bottleneck, 
then the parser will be non-compliant if optimized.  See item 2.
Tradeoff ubiquity and overall reliability for performance.

    6 XML documents should be human-legible and reasonably clear.

Choose between human readable and human typeable.   Signs 
always require training if indexical, and guesswork if 
symbolic.  Iconic is easier.  Tag designers are caught 
between the smallIsBeautiful vs gnosticIsEvil camps.  SNAFU.

    7 The XML design should be prepared quickly.

Ok.  Speed to market vs haste makes waste.  I'm glad it was done 
before the dot.com bubble burst.  It took a while anyway and 
that was with most of the parties already knowing where they 
wanted to go with it.  Committee effort works that way.

    8 The design of XML shall be formal and concise.

Good idea.  "Conserve nouns." - Dr. C. Goldfarb

    9 XML documents shall be easy to create.

See item 2.

    10 Terseness in XML markup is of minimal importance.

See item 2.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS