Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: YAML Ain't Markup Language
 From: "Jonathan Robie" <jonathan.robie@d...> > 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 [expletive deleted] 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
