Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] Interesting pair of comments (was Re: [xml-dev] Schema Experience Workshop minutes online)

From: "Dare Obasanjo" <dareo@---------.--->
To: "Rick Jelliffe" <ricko@-------.---.-->,<xml-dev@-----.---.--->
Date: 7/11/2005 12:43:00 AM
Data binding tools use schemas for type information so you could say they use them for PSVI [in a way] but not validation. Many of the interop problems are of the form "my tool can bind to schemas with construct X while my business partner's can't". A real world example of this is trying to send nillable types back and forth between Java and .NET XML Web Service toolkits. 
 
-- 
PITHY WORDS OF WISDOM
A meeting is an event at which the minutes are kept and the hours are lost. 

________________________________

From: Rick Jelliffe [mailto:ricko@a...]
Sent: Sat 7/9/2005 12:15 PM
To: xml-dev@l...
Subject: [xml-dev] Interesting pair of comments (was Re: [xml-dev] Schema Experience Workshop minutes online)



Interesting to read two comments in tandem:

> Rogue Wave: "Many customer issues come from schemas that are not valid. In
> almost all cases this is the result of a schema generated by a tool."

WS-I: "...few web services implementers use validating XML Schema
processors. Many users "validate" SOAP messages using only inherent
SOAP-processing mechanisms, possible with some uncoordinated help from
type serializers. This situation often means that XML Schema constructs
like tyoe facets and PSVI are ignored when web services messages are being
processed, which in turn discourages the use of such constructs by Schema
Authors."

Putting these two together, I find a paradox:

When you are using a platform-specific data binding tool, it will generate
good quality code for serializing the data into XML/SOAP and then
recreating the objects at the other end fine. And it will also generate an
XML Schema,
if it didn't use a custom annotated one for its template.

But that XML schema may be suspect or unacceptable to other tools. But no
worries, the other end probably does not validate with the XML Schema or
use its typing, anyway.

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.

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.

With knitted brow
Rick Jelliffe

P.S. Full disclosure: my company Topologi makes validating tools of
various kinds, including online tools for web services. We have a great
new one, Interceptor, coming out next week sometime. We support XML
Schemas (as well as Schematron, RELAX NG, DTDs). I certainly have a
commercial interest in promoting validation, whether by XML Schemas or by
some higher-level language like Schematron. So I hope no-one dismissed my
comments as some kind of FUD about XML Schemas: it is one source of my
bread and butter too, not some idle spoiling.


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent