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] YAML Ain't Markup Language

[ Lists Home | Date Index | Thread Index ]

From: "Jonathan Robie" <jonathan.robie@datadirect-technologies.com>

> I consider W3C XML Schema too complex for its functionality, but the above 
> statement is really pretty ignorant.
> 
> Unless you mean it in the following way: any XML document can be processed 
> in ways that were once reserved for data stored in databases. 

?? But nothing in Jonathan's example requires or uses W3C XML Schemas.
Furthermore, the same kind of query could be done in XSLT and, indeed,
in OmniMark or the various text processing languages people used with SGML.
Extracting trees of information based on pattern-matching values has been around
since markup languages were invented: auto-generated indexes for example. 
I don't really see Jonathan's point here.

From my POV, in my time as a member of the W3C XML Schemas WG, I cannot
recall a *single* feature added to support publishing requirements (i.e. any additions
that were not aimed at merely reconstructing DTDs or were also DBMS requirements).

Such features could have included (but didn't) : being able to constrain mixed content
data, co-occurrence constraints of various kinds, data-typing based on mapping idiomatic
lexical forms to standard types, a module system (the trouble with "reconstructing what 
parameter entities do" is that, when the rubber hit the road with attempting to reconstruct 
what XHTML modularization did, WXS had not  "reconstructed" all the bits of parameter 
entities used for versioning and customizing). Indeed, one pretty obvious way you 
can tell that WXS was not designed with publishing requirements to the fore was
that it could have "reconstructed" SGML's features (#CURRENT etc) for non-resolved
documents. Or provided link typing.

If you look at what was new in WXS: the type extension mechanism (by suffixation) is clearly 
too crippled for publishing requirements (you need to have a new element in the middle,
you have to add it to the base schema then remove it again explicitly from all the derived 
schemas, or perhaps just lengthen the derivation chain with a new progenitor: yech), 
and xsi:nil, these are clearly not driven by publishing requirements. 

The most important question does not concern individual features, nor their negotiation, 
nor who were goodies and baddies, nor attacking these straw men who don't think 
queries are useful, etc, but the deeper question of whether type lattices are appropriate 
as the central organizing principle of new XML-family standards. 

That is a major architectural decision: for people who don't need type lattices, of course
they will feel pissed off that the base-level of XML technology is being complicated (presumably 
Perry Mason could find the culprits quickly.) But from the baroque (SGML) to classical
(XML) to primitivist (YAML) to conceptual art (WXS), why should everyone
like the same art?

Cheers
Rick Jelliffe





 

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

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