Re: Document oriented experience reports anyone?
> 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  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  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.
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