[
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.
len
|
