[
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/
|
