Slashdot Mirror
Authoring Schemas With XSD
Dare Obasanjo points to his own "article on O'Reilly's XML.com that specifies a set of guidlelines for authoring schemas using the W3C XML Schema Definition language commonly abbreviated as XSD. The primary theme is embracing simplicity by showing how to avoid the more complex and esoteric features of the language."
I think misrepresentations like these from story submitters ultimately detract from the overall quality of the articles and I'm sure that the author wouldn't be all too thrilled about it.
It's akin to those Costco salespeople who tell me that the "shweet" HP computer over there has 20GB of "RAM". It looks a bit dumb given the target audience.
James Clark fights with XSD, pushing his Relax NG. Relax NG is *not* W3C. Let me repeat a background.g 00 217.html
XML (markup language created by W3C) is a subset of SGML (markup language created by ISO).
XML has been created by few smart marginals from SGML world plus some MS politicians
Now those MS politicians (and alikes) rule the show in W3C and the smart marginals have left W3C and work for ISO ( OASIS ).
XSD is XML Schema language by W3C. Relax NG is XML Schema language by ISO (OASIS). Sofar, Relax NG is the first visible XML applicatuon which belongs not to W3C
Now when we have a big picture written down, I would recommend reading the letter from James Clark
http://www.imc.org/ietf-xml-use/mail-archive/ms
The RELAX NG formalism has a solid basis in tree automata theory. W3C XML Schema has no such basis.
e t.c.
BTW, even RELAX NG is definately better than XSD, Relax NG itself is also not that perfect. The 'perfect' solution could be based on regular expressions. Nevermind. In the next years, nothing interesting (except for political battles) would happen in the world of XML Schema.
"This must be a Thursday, I never could get the hang of Thursdays."
A client will call an API such as getFOO which will have an input type of InputGetFoo and an output type of OutputGetFoo defined in an xsd file. Because both our system and the client use the same xsd files, there is very little problem with synchronization. Using xml allows our clients to have a heterogenuous environment; anything that can deliever xml over tcp/ip can use our interface.
.. there were certain parties whom overwhelmed by its newness, complexity and buggy implementations..
Kind of like Microsoft, who instead of working with the spec at all, decide to create their own Schema impl. called the "Biztalk Schema". Which is all but useless outside the Biztalk Mapper app. I think their motivation for this was that implementing an XSLT generator that could map two w3c schemas together would be too useful to the public, and would involve too many non-M$ proprietary technologies.
A while back I ran into a rather stupid bug in RedHat. After some debugging I figured out the problem was due to a "description" field missing from one of the config files (/boot/module-info).
At the top of this file in the "comments" was a brief note about the format that this file was supposed to follow. According to this, there should never have been an entry without a description field. The code for one of the GUI programs ASS-U-MEd this would be the case, didn't do any checking and of course crapped out when it found a malformed entry (someone obviously hadn't read the format info in the comments when the made changes).
Now of course the code should have been robust enough to handle such and error, but ideally there would have been some checking of the config file to determine whether the file actually conformed to the listed format rules before it was sent out into production.
These config files are where XML's strengths can be quite useful. If this file had a formal schema definition and was created in XML, it would be quite easy to check this config file for correctness (syntactical at least) as part of the build process. The code which reads these files could be changed to use a simple XML parser to read through it, or hell you could even write an XSLT transform to turn it into the "non-XML" format (i.e. use the XML for developing the file only) and not have to change any of the existing code that reads that file!
There's been a big push towards XML configuration files in some segments of the industry (the Java J2EE camp for example). I for one hope this trend will continue.
They wrote a schema as well as a DTD (which has the usual namespace validity problems). XSD may be big and ugly, but the designers would have noticed if it couldn't even describe itself.
Then maybe you just shouldn't be doing such "complex" programming. XSD should not take more than a couple days to understand, another few days to iron out the details, and by the end of 30-40 hours you should have produced a good sample of whatever you're modelling with XSD.
Too many "how to" documents and books are written for people who just don't "get it". While I sympathise that they need to learn, you have to grasp the concept of abstraction before some of these "languages" make sense. XSD, ERDs, SQL-DDL, etc. are just different ways of describing data structures and organization. Each is "complex" if you try to make it do more than it was intended for, but only takes a couple weeks to understand well enough to get by.
I do not fail; I succeed at finding out what does not work.
I don't think people should be able to just make up their own standards.
Isn't that the whole point of XML to begin with? That my company and the company we're partnering with can write a simple data-exchange standard without locking both development teams in a conference room for two weeks?
So, in your case, you and whoever your dealing with could pretty easily nail down what kind of namespace smarts you want in your DTD validations and implement it without having to RFC the whole world.
All's true that is mistrusted