Slashdot Mirror
XML Schema a W3C Recommendation
J1 writes: "The World Wide Web Consortium has officially given its Stamp of Approval to the XML Schema specification. This makes it an official W3C Recommendation. The press release has the details."
← Back to Stories (view on slashdot.org)
So what is the big deal with XML Schema? XML Schema is important because it provides the widgets to define a "card catalogue" for your library of data, be it air plane parts, phone bill, hotel reservations, or porn.
Now metadata has been with us since the mud table libraries of Mesopotamia (they had indexes of stuff so they could find how many cows were traded in the Xth year of SomeRulerDude), however the printing press is what made all the difference. You see, before the printing press books were so expensive and time consuming to write, there were not that many of them. The general strategy to manage a library was an index of all the books. As long as the book population was not too big, then this works. For example, when you search on google for "McCain", you get congressman, porn sites, and damn near everything in between. Search engines today are just really, really big indexes of stuff. Still in the stone ages, aye?
The printing press changed that and forced libraries to find an EXTENSIBLE way to keep up with books. The Dewey Decimal System is a great example. So I pose to you the following question, "When was the last time the DDS was updated?" Well, how long have they been publishing books on computer science, biogenetics, or nanotechnology. The DDS is an extensible system to classify knowledge. So I leave you with the following statement...
HTML was the functional equivalent of the printing press, which is just an electronic version of fast, cheap publication. HTML forced us to follow down the path of XML, just like the printing press forced Mister Dewey to put on his thinking cap. The only difference is that the printing press took a few hundred years to do its thing where HTML only took a few years to do its thing.
Now for all the other XML specs out there (SAX & DOM, RDF, XSLT, XHTML, XPointer, etc) are just tools to work with your (library of) data. Better to have many specialized tools that can evolve independently than one big honking tool, aye? Use only the tools you need.
So does TBL's dream of a semantic web make more sense now...?
If you want some links, try...
Danny Hillis - The big picture
Roger Costello's XML Schema Tutorials
"You can drive a car by looking in the rear view mirror as long as nothing is ahead of you. Not enough software professionals are engaged in forward thinking." - Bill Joy
While somewhat important, I think that people give data validation far too high of a priority. People seem to think that "self-describing data" is going to save the world in the same way that XML was supposed to eliminate the need for parsing and interpretation of information by a computer program. I've been involved in using XML to exchange information and make remote invocations of services in a Web environment, and you still have to write programs to interpret the contents of the XML information in pretty much the same way as with data exchanged in any format.
So you can automatically validate it. So frikking what! The rabid theoriticians in the consortium of people that I work with get all hung up on this without realizing that most functioning protocols out there are able to exchange information without the need for a formal validation model. Not that you would really want to use one on either the generation or consumption side of a real system, since it just slows things down. All you need is a clear spec for the protocol.
Another thing that bugs me is the fiercely defended text-only approach used in XML. For some reason, XML fans seem to think that computers cannot exchange and understand binary data, or that editing tools would be unable to allow people to see it.
The text-only approach has two major limitations. First, there's no way to directly include binary data. There's lots of binary-encoded objects out there, like image or sound file formats, but you have to encode it in BASE64 or something. This is pretty strangely limited given that XML data is generally exchanged over an 8-bit clean pipe (i.e., the Web). Something like:
<xml:binary size=10>kjiu õéçäá</xml:binary>
would be quite reasonable, with "size" octets placed directly between the closing '>' of the opening tag and the opening '' of the close tag. They should have included a mechanism in XML Schema to declare this.
The second problem with text is the high cost of parsing it. Probably the majority of time spent in a system that processes a large bulk of XML data is spent in the lexical analysis stage of consuming the XML stream. They had their big chance with binary-WAP-XML, or whatever they called it, but that seems to be kind of screwed up and includes patented technology. What is needed is a simple, widely acceptable binary encoding of exactly the information included in XML text, which uses lookup tables to optimize handling tag names.
The third problem with exchanging raw text XML encoded data is that it explodes the information you want to ship over the Web by a factor of about 20 times. It needs to become commonly accepted practice to, at least, exchange this information in a compressed format, such as GZIP. The MIME tags really need to be updated too, to allow a nesting of formats, to say "this is a gzip-compressed stream of Bob's fabulous graphics markup format encoded in XML".
What we are waiting for is XQuery, that will hopefully make a big difference :-)
You might want to have a look at Kweelt which claim to (and I quote) "implements a query language for XML that satisfies all the requirements from the W3C query-language-requirements"
Is this what you're waiting for?
--jw
There's a host of languages you can use to pull subsets of XML data out. Everything from XPath expressions with XSLT to building DOM trees or SAX parsers to manipulate the data with your favorite programming language. That's as powerful as you can get.
large-scale use are yet to come.
Reuters produces all their news in XML format. There's a contant stream that comes in at a few MB an hour. That's a massice scale use if you ask me.
To all you stating that now this is a "standard" organizations will start "breaking" it:
It is not a standard, it is an official W3C recommendation. And part of the process of making it a standard is for developers to experiment with it to see what works and what doesn't. So whereas some propietary extensions die out, some survive and become part of the standard.
So now that it's a standard:
Microsoft already supposed XSD schemas in the MSXML 4 preview release. Microsoft has been more of a force in pushing the implementation of XML than any other company, so to fault them unjustly seems quite silly.
Just look at how unified html has become!
I am not a spork.
As you can clearly see, the old system was just far too unwieldy and complex. I am glad that they have made things so much simpler.
XML has needed a truly powerful schema language to enforce data constraints in data-heavy documents. This is very much akin to having database schema for databases. With a declarative language and a common processor enforcing primary constraints on data, you free each application from having to do their own consistency checks.
XML Schema has a lot of powerful features, including the separation of types from structure, two kinds of type inheritance, modularization, default values for attributes and simple elements, and the flexibility to be as strict or as lax as the situation dictates for validation.
Having said that, the big battle brewing is whether XML Schema is going to be shoehorned into all the other XML protocals that need a data model description before there's been a wide base of practical experience developed. There's already a divide between data modelers and application developers because of the specialized knowledge that SQL and relational database design imposes; I think XML Schema does nothing to narrow that gap, which is unfortunate since class hierarchies and the hierarchical data model of XML seem a natural fit.
If you post it, they will read.
Not to detract from the humour value of your post, let me give a simple example of everyday XML usage where schemas are essential for XML.
You've got a database, with a 2 column table. Say "Company name"(char[40]) and "Net profit this year"(int). Ywanna get data to go in this table, in XML format, from another company. That XML's gonna look something like this:
Ok. Now how do you specify that the Company name should be <= 40 characters and the profit should be an integer? A DTD gives no way of doing this, it just says what order the tags can come in. Without XML schema, you're reduced to sending emails saying "Please make the Company name at most 40 chars and please make Profit a signed integer". Which is evil, cos you might have to do that for a 200 table database, and also there's no way of using that email to automatically check that XML file.
OTOH a schema lets you specify exactly what you want in a precise, even fairly simple, machine-readable format.
Now do you believe me that schemas are really important? :-)
perl -e 'fork||print for split//,"hahahaha"'
First, for XML itself. What is XML? A standard way to store and describe data in a manner that is readily addressable by virtually any computing platform. I could write Vic20 programs that handle XML (to a limited degree, 4K ain't much to work with). What else offers that? Let's examine a couple alternative data formats that, while not a comprehensive sample, illustrate the problem with non-XML formats. First, a comma-delimited format is pretty well standardized and can be addressed on virtually any computing platform -- but the data is not described. A database in Visual FoxPro provides column names that describe the data -- but it's not readily addressable on a wide variety of platforms (at least not directly). Thus, XML provides the data and the description, even including the relationship among data (i.e., the 'name' is a component of the 'customer').
So what's the Schema big deal? Well, with XML alone, you can't give someone a data format to follow which provides type checking, length restrictions, etc. If you're trading data with someone, you not only want to know the names and relationships of the data fields, and the data itself, you also want to know how the data will be formed. Is it an integer? Is it a 20 character field? You could presumably build a proprietary extension to XML that would allow you to describe those constraints, but why go through that trouble to get an end result that works only for you, when you can take a pre-built language for describing those constraints which works for everyone?
If you want to just store your own data, and you're certain that you'll never change your software, then XML doesn't offer much. It's not the most compact format. But if you exchange data with others, and/or if you are likely to change your data management software, XML becomes a valuable tool, and the Schema spec strengthens it considerably.
(Caveat: I'm relatively new to XML and am definitely in learning mode. The above describes the benefits I see from the viewpoint of someone who has several very messy data exchanges to clean up.)
No Laughing Allowed!
DTDs are rules on how the document is to be "formatted". In other words, where certain elements and tags are to be placed within a document. This refers to the document's structure. Liken it to HTML .. most HTML files have <html><body> then </body></html> tags (in that order). So long as those are in the correct order (as specified by the DTD), the document is "verified" correct by a validating parser. Yet, this has nothing to do with the data between those tags.
This is where schemas come in. They represent a validation against not only the document's structure, but also the data it contains (i.e., the data between the tags). You could liken it to the constraint on a database table's field. I.e., CustomerType = V or I (Valid, or Invalid). To continue the example from above, you could specify a schema the restricts the content of the data between the html and body tags.
Hope this helps.