- From: <paul.downey@bt.com>
- Date: Mon, 11 Jul 2005 15:52:20 +0100
- To: <ryman@ca.ibm.com>, <dorchard@bea.com>
- Cc: <www-ws-desc@w3.org>, <www-ws-desc-request@w3.org>
Arthur I think I was initially troubled by your concern for similar reasons, but I now see the proposal for LC124 quite differently to SOAP encoding. > The point about SOAP encoding is that WSDL 1.1 used XML Schema to describe > messages that were SOAP encoded, but of course the messages didn't in > general validate against that schema. Rather, WSDL 1.1 was being creative > in its use of XSD by saying that it was just the abstract definition of > the message. Agreed. Even if you could flattened the multi-ref structure into a canonical form using a concocted method, you couldn't rely upon a schema validator to constrain the message contents thanks to annotations such as soapenc:arrayType. > Now we are being asked to entertain a similar creative use of XSD in that > it is initial version of a family of schema versions and the messages > validate against any member of the family rather than the initial one the > appears in the WSDL 2.0 document. I'd content that for any WSDL there isn't 'one', but rather a family of different valid messages may exist for any single schema, in the same way it's possible to have invalid messages which are valid according to the schema. This is in part because of the layering of the Infoset; there may be structured comments or processing instructions, but mainly because it's simply not possible to express all of the validation rules a document must conform to to be 'acceptable'. > In neither case are we to interpret the schema literally. That is true, but for ignoreUnknowns we maintain the ability to schema validate the presence and form and content of the parts of the message a receiver is reliant upon being present for processing, which I contend is the 99+ case in messaging. Paul
Received on Monday, 11 July 2005 14:52:29 UTC