Re: Interesting pair of comments (was Re: Schema Exp
On 7/9/05, Rick Jelliffe <ricko@a...> wrote: > The paradox? The way to use XML Schemas successfully in multi-vendor web > services is to just pretend to use them. The schema and/or WSDL become > just documentation, and should not be considered translatable > specifications. I'm not sure there is a paradox here. The problem that RogueWave (and several others) noted is that many schemas out in the wild are not valid instances of the XSD spec. That's mainly due to the historical lack of conformant support for the XSD spec by tool vendors, a situation which has been mostly corrected in the last year AFAIK. Obviously a data binding or validation generated by an invalid schema is going to have interop problems, but that's not exactly paradoxical -- the way to fix this sort of problem is to just fix the implementations. I think that was one major point of consensus at the workshop. > > Is that what is happening? If most multi-vendor web service servers do not > actually use the XML Schemas (e.g. for validation, or for PSVI), then we > might do well to up-weight the significance of bad interop reports: if > only a few people have interop problems, but it turns out that only a few > people actually use schema validation/typing/PSVI, then interop could be > worse than we hope. The data binding / object serialization problems are more complex, but again not exactly paradoxical. The root of the problems is that XSD has a much richer (and admittedly more bizarre) type system than the programming languages in wide use today. People have been rather creative in mapping XSD constructs to CLR and JVM constructs, and these creative mappings don't interoperate very well. The solution here is much less clear and there is (IMHO, not necessarily MS's) probably a lot of experimentation left to do before standardization is appropriate. I think most of us agree that the XML community has dug itself into a hole here. The obvious first thing to do is "stop digging", i.e. let's not produce another major version of XSD until 1.0 is clarified, debugged, and widely implemented properly. It's less obvious whether the optimal way out is to shore up the hole we've dug or to extricate ourselves and fill it in. I get the impression from reading and talking about the workshop that most people, as much as they might like to fill in the %$##@ hole and start over, realize that there's too much invested, and too much actual value being realized from XSD by those who stay away from the crumbly edges of the hole, to make it worthwhile to start over. Alternatives such as RELAX NG are arguably better for structured textual documents, but don't easily meet the widespread need for object serialization and *business* documents with a lot of typed data in them. I think the typical xml-dev participant tends to be in the structured textual document camp, but for better or worse the silent majority of actual XML users out there seem to be mostly in the object serialization / messaging / data-intensive business document camps. In the short term, to paraphrase Rick somewhat, the way to use XML Schemas successfully in multi-vendor web services is to use the parts of the spec that really do interoperate for object serialization. That will take some work -- maybe by W3C, maybe by WS-I, maybe by vertical industry organizations -- to identify, but progress is being made. The idea of the Wiki mentioned in the workshop proceedings was to have a common reference point and discussion forum for this kind of thing, I believe. In the longer term, clarification and correction of the spec, and better and more interoperable implementation of the spec, should greatly reduce the problems that the two comments refer to.
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