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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: intertwined specs

-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com]

>Well, let's put it another way.  Three years ago, the W3C published a 
>document which listed these goals:
>1. XML shall be straightforwardly usable over the Internet.

That might have been restated, "XML shall not 
obsolete other usable specifications, eg, HTML, HTTP, URN/URI/URL and 
so on" but so far so good.

>2. XML shall support a wide variety of applications.

XHTML, SVG, X3D, MathML, now HumanML.  Varied yes?

>3. XML shall be compatible with SGML.

By painful process and uncomfortable output, still true.

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

Varies by program type.  This can't be proved for the general case 
because we don't have a general case.

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

Depends on the scope of the thing denoted by "XML".  "Ideally" translates 
"not really" if you include all of the XML vocabularies.

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

That is an admonishment to schema designers.  As meta as you like.

>7. The XML design should be prepared quickly.

Did that.  

>8. The design of XML shall be formal and concise.


>9. XML documents shall be easy to create.

Application dependant.  Nice goal, but just nice.

>10. Terseness in XML markup is of minimal importance.

Gotta talk to the schema designers and compression gurus here. 
It is certainly of varying importance.

>I think it's reasonable to suggest that XML - read broadly as the then XML 
>family of specs - lived up to that in 1998.  I think most of those, except 
>perhaps 2, 10, and maybe 9, don't apply to the current and developing XML 
>family of specs.

If you want XML to be used in "a wide variety of applications", ease 
for the entire family of XML specs becomes an ideal, and again, not really.
We can talk modularity vs monolith here, but fact is, no size fits all 
comfortably.  That intertwining is there to ensure that as you let 
the dress out, the hems don't rip.

>For those of us who really savored the goals above, I'm not sure this 
>qualifies as progress. (And no, XML 1.0 hasn't changed much, but 'XML'

I think that is so, but all evolution is not progress.  It is evolution. 
This complexity curve is inevitable.  As the tower grows taller, the 
base grows wider (if you build top down).  If you build bottom up, 
the base must be as wide as the components of the tower enable it 
to get high.   Somewhere between earth and heaven, the walls come 
tumbling down.  

Do you feel a rumbling?


Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h