Why make Atom XSD friendly?
From mailing list - * Usually provides a terse and concise description of the vocaublary [relative to the prose of the spec] * Enables software to validate that XML documents being received from clients or servers actually conform to the vocabulary. This prevents issues like each application hacking up its own validator or "liberal RSS parser". * Allows vocabulary to co-exist with technologies and tools that already support features specific to a schema language such as relational to XML mapping, object to XML mapping, directed editting, etc.
From mailing list - RSS went down the schema-less path. In fact, DTD support was originally built-in and abandoned over time. Without a schema, the only way to validate your RSS was to build the Feed Validator. And we thank the authors for that. But there's still hundreds of bad RSS files out there. Other people tried to solve the problem by writing 10k line C++/Java/Perl/PHP/Python libraries that wrote valid RSS for you. In fact, everybody wrote their own library. I wrote at least a dozen of them
Now if we had an XSD, then you could validate a feed with a few lines of code:
reader = new XmlTextReader("rss.xml"); vreader = new XmlValidatingReader(reader); vreader.Schemas.Add("rss.xsd"); vreader.Read();
or something like that.
Going a step further, people have started writing XSD code generators like Microsoft's XSD.exe. Type
XSD rss.xsd /c
and you get a bunch of C# classes that read and write RSS. Example
Use these classes and your chance of producing bad RSS would be near nil. Write your own and well, most of us write bugs for a living. That's why there's so much bad RSS in the first place.
Another great tool is XMLSpy. Give it a schema and it'll help you create an XML document for that vocabulary. In fact, give it a schema and it'll help you send a SOAP request using the vocabulary.
What does this mean? Given an XSD, nobody has to write a validator, nobody has to write a C# library, nobody has to write a Java library and nobody has to write a test harness. Any XML vocabulary that has an XSD already has these out of the box.
How to make Atom XSD friendly?
Atom in its current (0.2) form requires two changes to make it Xsd friendly.
Elements should be ordered.
Multipart/Alternative must be respecified in a more deterministic form.
Why must elements be ordered in XSD?
This is actually an intentional limitation of XSD.
From mailing list - Short version: You can either use xs:all in which case all of the elements must occur only once or be optional (maxOccurs="1") and you can't have extension elements or you can use an xs:choice with maxOccurs="unbounded" but then you can't limit how that each unordered element only occurs once.
Why must Multipart/Alternative be respecified?
From mailing list - It's really complex and I can't seem to write XSD that can be used by the various tools. It would make it much easier if the multipart thing was not an attribute value, but an element name.