- From: Roberto Chinnici <Roberto.Chinnici@Sun.COM>
- Date: Wed, 07 May 2003 15:02:33 -0700
- To: www-ws-desc@w3.org
I had an action item to explain some of the issues with XML Schema that could lead to subsetting it in the Web services space. The basic problem I see is that SOAP is an enveloping technology for blocks which are meant to be processed independently. But XML Schema (and XML itself, e.g. with ID/IDREF) allows one to specify constraints whose validation rules are applied across the whole document. So, for instance, an application that generates a XML fragment that will become a block in a SOAP envelope must take same care when specifying the value for an attribute of type xsd:ID, as a poor choice would result in an invalid *envelope*. Notice that if the fragment was considered in isolation, i.e. as a mini-document, it would be valid. Where it gets tricky is that, in order to make sure that the resulting document is valid, the application must have full knowledge of the schemas for *all* the blocks (because any attribute could be an ID). The converse, a fragment that is invalid in isolation but becomes valid in the context of a larger document, can be readily demonstrated using an attribute of type xsd:IDREF whose value doesn't match any IDs in the fragment. Initially I thought the same problem would apply to identity constraints in schema, but now that I found out that the XPath expressions in the <xsd:selector/> element must use the "child" axis I don't think that's the case. In other words, these constraints always operate within a fragment. Hopefully some of the schema gurus on this list will jump in and confirm or reject my conclusions... ;-) Roberto -- Roberto Chinnici Web Technologies and Standards Sun Microsystems, Inc. roberto.chinnici@sun.com
Received on Wednesday, 7 May 2003 18:39:40 UTC