[
Lists Home |
Date Index |
Thread Index
]
On 7/9/05, Rick Jelliffe <ricko@allette.com.au> 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.
|
