[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Document oriented experience reports anyone?

Re:  Document oriented experience reports anyone?
Just for a small example, how about a subset in which 
elementFormDefault="qualified" and attributeFormDefault="unqualified" 
are the default and only options, as the XML Namespaces spec envisioned?

Bob Foster

Robin Berjon wrote:
> Hi Henry,
> Henry S. Thompson wrote:
>> Robin Berjon writes:
>>>  * 85% of XML Schema is thoroughly useless and without value;
>> Wow!  Please identify the 15% you used -- there are lots of people
>> interested in profiling XML Schema, your input would help.
> I could identify the parts I used (elements, attributes, data types) and 
> the parts I was forced to use (complex types, the small subset you can't 
> get around) and while that would probably not amount to even 15% of the 
> text in part 1, it would not be very useful feedback for the profiling 
> you mention.
> To be perfectly honest regarding the feature-set of XML Schema, I am 
> told and can observe myself very regularly that people are using it to 
> map XML to databases, map XML to object systems, etc. and I find that 
> wonderful. Few specs get to have people do so many things with them, and 
> that should be celebrated.
> Me, I'm mostly interested in validating XML documents, or rather in the 
> ability to use a schema to describe as many aspects of its instances as 
> possible. And there are many aspects to a document. And, still being 
> honest, I'm still waiting for the W3C spec to do that.
> I don't want the features in there I don't need to go away. If people 
> are using them, they definitely need to stay. I do however want them out 
> of my sight, because I really don't want to have to deal with them if I 
> implement a schema processor. Also, I don't particularly want the 
> features I feel I missing to go into a monolithic XML Schema 2.0 spec 
> because I don't think that adding to the current weight is going to do 
> any good.
> All I'm, at heart, asking for, is modularization. Cut it up into small 
> manageable pieces, just like XML Schema was cut in two, but more so. And 
> then we can add all sorts of small modules of interest to various 
> communities. I understand the draw to have the One Schema Spec To 
> Describe All XML, but that's just not possible. Admitting defeat on that 
> front would be victory. The logic of interoperability seems to demand 
> one spec, but there are cases in which it simply won't work out.
> I can't believe how much heat the binary XML people are getting with 
> people saying that a generic solution can't be found there without any 
> of those people bringing any proof of that to the table, while no one 
> seems to notice that in a schema language, something as fundamemental as 
> local determinism makes it useless to people like me, and the lack 
> thereof makes it useless to others :)
> I think the DSDL effort gets it right by cutting things into smaller 
> bits. Whether it's the right way to cut things up is a topic for 
> discussion, but I really don't see how else we can go about this.
> There is a need for an interop spec, and that can remain the XML Schema 
> spec, including a number of modules by reference. But users just need to 
> pick the parts that are of use to them. Otherwise everyone will just be 
> using their own 15%, and the squirrels will come back.
>>>  * the few useful features are weak and without honour;
>> That seems harsh -- could you be a bit more specific?  Take content
>> models (I presume they're useful) -- what's weak and without honour
>> about reconstructing sequence and choice, optionality and iteration,
>> from DTDs into XML notation?
> It is harsh, as any Klingon quote would be. You bring up notation and 
> it's definitely a part of it. At a very simple level, the descriptive 
> power to number of characters ratio just got lost between two keys on my 
> keyboard. But I guess everyone but me and the three other people 
> complaining uses IDEs and never sees the XML so it probably doesn't matter.
> On another level, I've created this cool vocabulary with which I'm doing 
> really cool stuff on the Web. I want a schema for it because validation 
> is good practice. Is there one single good reason why I should know what 
> "deterministic content model" means, or even hear that sentence uttered 
> if only once?
>>>  * creating a modularized XML Schema is easier than with DTDs, but
>>>    nowhere near as simple as with RNG;
>> Where does the difficulty lie -- notation or substance?
> Allow me to answer with a question: where in XML Schema is NVDL?
>>>  * 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;
>> That's me (although _my_ moor was very conservative, not wasteful at
>> all :-)
> A thatcherian moor? I had no idea, I am ever so sorry :)
>>>  * the resulting schema is mostly useless anyway as there is no tool
>>>    available that will process it correctly.
>> Really?  Xerces, .NET, saxon, XSV don't count?
> I should have dated the post more explicitly, it was about SVG 1.1, 
> which came out two years ago. Things are now better (though nowhere near 
> perfect). Nevertheless the amount of time it is still taking to get 
> reliable interoperability between implementations of a spec that has had 
> solid vendor support as few others have is an indication that something 
> is wrong with the spec. I don't pretend to know exactly where, but I'm 
> thinking the size and complexity of the spec don't help, especially when 
> most people just exercize small parts of it. I'm pushing the notion of 
> modularization (as others have before me) because I really think it's 
> the only way of making this manageable.
> I know my post was harsh, it wasn't personal but it certainly was deeply 
> heartfelt. I work for a company that uses XML Schema intensively, most 
> of the time other people's schemata. I've spent literally months of my 
> lifetime fixing schemata that "work in XML Spy" or "work in Xerces" but 
> simply weren't compliant at very simple level. Now that the tools are 
> better it's more about handling impossibly weird constructs that the 
> spec tolerates and obviously natural ones that it doesn't. Whenever I 
> open an XML Schema document, I twitch violently until I see 
> elementFormDefault="qualified" (and then I drool a bit, but that's 
> mostly for effect). Yes it's made me bitter at 28, and yes I see 
> xsi:type attributes attack me in my sleep, and yes RelaxNG has had none 
> of these side-effects.
> So please cut it down into small pieces that we can handle. *Please*
> I like you comparison with Java, having had a similar experience. I'm 
> personally expecting to start finding it usable in three or four 
> iterations. I'd just like that to happen several years earlier with XML 
> Schema :)


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.