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] Document oriented experience reports anyone?

[ Lists Home | Date Index | Thread Index ]

Hi Jeff!

Jeff Rafter wrote:
>> I wrote an XML Schema for SVG Full 1.1, and another for SVG Tiny 1.1. 
>> Doing so taught me a number of things:
> 
> For the record I would say that SVG is *not* a document oriented format. 
> This may be a crazy position to take, but for the most part the thing 
> that makes SVG documents document oriented are the ability to use 
> various elements in various orders in various places. Other than that 
> the metadata and structures are very data oriented.

It's not crazy, as you well know I picked SVG on purpose out of quite a 
few other schemata I've written, precisely because SVG is documents but 
the format is quite data oriented (provided the difference means 
anything, but that's another permathread).

I think however that there's one thing that makes SVG more document 
oriented and it's the intent: it's meant to be used in close, 
uncompartimented conjunction with other vocabularies. If you write a 
schema for XHTML and I write a schema for SVG, we want them to just work 
together magically. With XML Schema, unless we've both been extremely 
smart and have talked about it behind the scenes, it'll be luck if it works.

> For example there is no mixed data and a <rect> cannot contain a <line>. 

Wrong, there is mixed data. And while it's true that a rect can't 
contain a line, in XHTML a head can't hold a p. A line (or in fact any 
element) can however contain all of the metadata elements, all of the 
animation elements, and the handler element. The syntax is quite loose.

>>  * 85% of XML Schema is thoroughly useless and without value;
> 
> When examining the breadth of the recommendation it is very clear that 
> the sections that are used the least (complexType restriction) are by 
> far the longest. But 85% is too high and "useless" is too strong. 
> "Unimplemented" may be better.

Yes, it was deliberately high and strong -- it's an xml-dev post :) But 
still, if you look at how much code coverage from a schema 
implementation you get out of reading a schema for SVG 1.1, I'd be 
surprised if you went above 20%.

>>  * the few useful features are weak and without honour;
> 
> Name 5 honourable specifications. I come up with only WAI stuff. Now if 
> you are referring to something like the claim that "XML Schema improves 
> cardinality constraints" which is rendered invalid by the memory 
> requirements needed to represent large integer FSMs for high maxOccurs 
> values... then.. well... I guess I will grant you that one.

No, you're right, I retract that claim. XML Schema's definition of the 
term absence on its own, if anything could, makes it worth the read.

>>  * while a zillion useless features have been included in the spec,
>>    anything useful such as making attributes part of the content model
>>    has obviously been weeded out with great care, basically leaving one
>>    with DTDs supporting namespaces, a few cardinality bits, no entities,
>>    and loads of cruft;
> 
> The supporting namespaces bits are important.

I'm not saying it's not, however I also don't think that adding 
namespace support to DTDs would warrant that many dead trees.

> There is also a very 
> data-oriented approach to object types in XML-- this probably takes up 
> the vast bulk of the spec.

Which is great for the folks who are doing that. I'm certainly not 
saying there shouldn't be a spec for that, it's clearly useful to some 
people. Heck, I might even find it useful myself in some cases. I just 
fail to see what it has to do at the core of XML technology.

That's at the heart of my gripe. Should all that database and object 
nonsense be core to XML? It's a known fact that no matter how many 
quality brains -- and the Schema WG sure had no shortage of those -- you 
throw at the problem of having all the ways of looking at data 
(including documents) that people need, you still will fail. Why not 
just agree that it won't happen, have a bunch of XML Schemata specs each 
addressing various needs, a big profile spec for vendors to bandy about 
their poor implementations of, call it a day and all have a beer? There 
are cases in which interoperability is needed, and cases in which it's 
impossible.

>>  * tools like XML Spy that are supposed to help one write schemata will
>>    produce very obviously wrong instances, meanwhile the syntax of XML
>>    Schema was obviously produced by someone who grew up at the bottom of
>>    a deep well in the middle of a dark, wasteful moor where he was
>>    tortured daily by abusive giant squirrels and wishes to share his
>>    pain with the world;
> 
> This? Coming from someone who prefers RELAX NG XML syntax to RNC?

Allow me to not even answer that comment :)

>> So my take is I'm not going to the workshop not because I don't want 
>> to give feedback about XML Schema, but simply because XML Schema is 
>> irrelevant. If I were president of the world I'd make XML Schema a 
>> chapter in the WSDL spec and use a combination of RelaxNG and 
>> Schematron instead.
> 
> Would you keep the data types section?

I have issues with it but it's roughly usable, and implementable. Given 
Regular Fragmentations it would probably be possible to cut out the 
kludges in it and leave opening up extensibility to other fundamental 
types to a more semantic level.

-- 
Robin Berjon
   Senior Research Scientist
   Expway, http://expway.com/






 

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

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