RE: LC124

Matt

I think saying validation "is not a requirement for any SOAP processor and certainly
not WSDL" is a bit strong. 

Validation is a part of the proposal since preserving the ability to validate messages 
does provide a proof of the correctness of the ignoreUnknows mechanism. 

I certainly do not wish to preclude processors from perfoming validation, and believe
such validation should be possible by an independent 'observer', as outlined here:
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0012.html

Paul



-----Original Message-----
From:	Matt Long [mailto:mlong@mvsquared.net]
Sent:	Mon 7/11/2005 8:45 AM
To:	Downey,PS,Paul,CXMA C; "peter.hendry@capeclear.com"
Cc:	www-ws-desc@w3.org
Subject:	RE: LC124

Hi Paul,

<Some_thoughts_from_the_field/>

These extensibility pattens are certainly useful in their own context.  However, they appear predicated on the fact that processor will what to perform a schema validation against the context.  This is not a requirement for any SOAP processor and certainly not WSDL.  It would be more appropriate (in imo) that the correct deserialization of the message is the primary goal.  Therefore, when extensibility is the a major concern across multiple business boundaries I have been using a Info Set representation of the message context at a high level.  This enables either the sender of receiver to build server | client to correctly deserialize the message and ignore the out-of-context-elements.  Understand, that the schema deployed across multiple nodes may in fact be very different, but each complies with the Xml Info Set representation.  If the receiver of the message wishes to validate the message against a schema, then the receiver can validate the wire Xml by creating a schema based on 

(1) required (non-optional) elements in the Info Set
(2) receiver's concrete extensibility elements
(3) <xs:any> extensibility elements (which implies 'ignore', i.e., not in receiver's context)

Notice, that I'm stating the the receiver is validating against a schema created by the receiver, not the sender.  This is because the message must be deserialized in the receiver's context, not the sender's.

This approach elievates the N*(N-1) issue when referencing x-node WSDLs, i.e., when 'n' nodes transmit and consume the same required information and each extends the message context independently and differently.  I do not think that extensibility patterns referenced address this issue (at least I think it's an issue).

Consider a node set A,B,C,D where each communicate the same core message, but each extend each it differently.  The number of required references to schema becomes 12, i.e., 4*(3-1).  One can only imagine the 'nasty-ness' (not to mention cost) of this when communicating the same core context (which MAY be extended by any node) across many nodes in a many-to-many node model.

I've addressed not a one-to-one scalable extensibility model, rather a many-to-many scalable extensibility model, which I think is the actual issue here.  

In summary,

(1) Schema validation is not required, but may be accomplished.
(2) Correct deserialization is required.
(3) Extensibility is accomplished in a many-to-many node relationship.


--
Matt Long
MV Squared Technologies
mlong@mvsquared.net
901-848-2640




	--------- Original Message --------
	From: paul.downey@bt.com
	To: "peter.hendry@capeclear.com" <peter.hendry@capeclear.com>
	Cc: www-ws-desc@w3.org
	Subject: RE: LC124
	Date: 11/07/05 03:17
	
	
	
	Pete,
	
	I don't quite follow your example. The additional values added in the v2
	schema are mandatory, so the schema would fail to validate a v1 message and wouldn't
	be backwards compatible with a client sending messages constructed using the 
	original schema.
	
	So the usual case in this kind of evolution is that the additional elements are marked 
	with minOccurs="0", and putting minOccurs="0" ahead of the "slurping vortex of the
	greedy xs:any wildcard"* violates UPA.
	
	This issue has been outlined in a number of papers, articles and conference 
	presentations, including one from our own Dave Orchard:
	http://www.xml.com/pub/a/2003/12/03/versioning.html
	
	by Dare Obsanjo, who offered a 'wrapper pattern' work-round:
	http://www.xml.com/pub/a/2004/07/21/design.html
	
	and I too dined out on this problem with a presentation:
	http://whatfettle.com/2004/09/XMLOpen/
	
	Even with Dare's suggestion, if all that was required was to add this magic 
	to the end of each and every sequence, and "some tool was generating the
	schemas" or those tools and everyone, in particular publishers of schemas
	for vertical standards, used this incantation already, then I'd agree,
	there wouldn't be an issue!
	
	LC124 isn't a request for syntactic sugar. Rather, that it isn't possible to write 
	compatible schemas to describe the simple evolution outlined by your example.
	
	Paul
	
	* more or less how Doug Purdy described it at the Schema Workshop
	
	
	
	-----Original Message-----
	From: Pete Hendry [mailto:peter.hendry@capeclear.com]
	Sent: Fri 7/8/2005 10:03 AM
	To: Downey,PS,Paul,CXMA C
	Cc: www-ws-desc@w3.org
	Subject: Re: LC124
	
	Ok. Another question. Why can't standard schema extensibility be used if a schema designer wants to be able to add elements in future?
	
	<complexType name="X">
	<sequence>
	<element name="name" type="string"/>
	<any namespace="##targetNamespace" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
	</sequence>
	<anyAttribute namespace="##targetNamespace" processContents="lax"/>
	</complexType>
	
	and then the new version of the type define other elements explicitely
	
	<complexType name="X">
	<sequence>
	<element name="name" type="string"/>
	<element name="id" type="string"/>
	<element name="age" type="int"/>
	<any namespace="##targetNamespace" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
	</sequence>
	<anyAttribute namespace="##targetNamespace" processContents="lax"/>
	</complexType>
	
	Then if a client using the original schema gets back a message containing
	
	<...>
	<name>Pete</name>
	<id>1234</id>
	<age>21</age>
	</...>
	
	it will at least still validate against the schema.
	
	It is obviously a bit of work to add this to each type but the expectation is that some tool is generating the schema so this is not a problem.
	
	Pete
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	



________________________________________________
Message sent using UebiMiau 2.7.2

Received on Monday, 11 July 2005 13:54:19 UTC