[
Lists Home |
Date Index |
Thread Index
]
> 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.
For example there is no mixed data and a <rect> cannot contain a <line>.
Except for the text sections of 1.2 there is virtually no flow in the
model at all. The impact of CSS flow and breaking is completely unknown
in the SVG world because SVG 1.1 limits the CSS properties available to
metadata properties attached to specific components.
> * 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.
> * 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.
> * creating a modularized XML Schema is easier than with DTDs, but
> nowhere near as simple as with RNG;
It depends.
> * 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. There is also a very
data-oriented approach to object types in XML-- this probably takes up
the vast bulk of the spec. One may argue that extension and restriction
are possible in RelaxNG but no one has done actual typing of constructs
from what I have seen...
> * 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? I
admit there are some confusing parts... but based on what you've said
you don't use any of those :)
> * the resulting schema is mostly useless anyway as there is no tool
> available that will process it correctly.
I believed this about a lot of features for a long time. Within the past
month I had to use redefine which I remembered working terribly across
various vendors. With very limited gotchas [1] it is possible to use
across all of the current processors.
> 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?
Cheers,
Jeff Rafter
[1] Some processors are flaky when it comes to bringing chameleon
components, redefining them, while simultaneously adding attributes from
another namespace. Separating this into two steps works fine. Also, I
haven't tested extensively in editors or data binding tools.
|
