RE: LC124

Pete

The motivation for ignoreUnknowns is to allow a Web service to evolve in a 
compatible fashion and avoid the need to publish and support multiple 
endpoints for each and every minor change to a service - the scenario 
I think you describe.

Flagging that a message may include additional content allows a v2 service to 
accept both v1 and v2 requests and always send v2 responses, safe in the 
knowledge that the client will ignore the optional additional content. 

This is not a narrow use-case, it represents the main use-case for evolving
services. WSDL should be able to easily describe and enshrine such scenarios.
The case where an incompatible change needs to be made results in a new
message namespace, operation, endpoint, service, as currently required for
most simple changes.

Our strong preference is for mustIgnores to be the norm and for strict validation to 
be optional, given the better data binding tools tend to work in this way anyway.
It has been our experience that tools which break on additional content are quite
often those which reject or fail to support the xs:any and xs:anyAttribute, making 
explicit extension points tricky to publish in an interoperable way. Publishing services
which practically interoperate with the lowest common denominator of toolkits 
is at best a difficult exercise, but when it comes to versioning scenarios, has so far
been neigh impossible. This proposal should go a long way to enshrining current
best practice when processing XML messages.

This issue, along with was the subject of discussion at the recent W3C Workshop on 
XML Schema 1.0 User Experiences attended by a number of Web service vendors:
http://www.w3.org/2005/03/xml-schema-user-program.html
 
Paul


-----Original Message-----
From:	www-ws-desc-request@w3.org on behalf of Pete Hendry
Sent:	Thu 7/7/2005 3:37 PM
To:	www-ws-desc@w3.org
Cc:	
Subject:	Re: LC124

Giving this some more thought (well, whatever my brain is capable of at 2:30am anyway), I would like to know the argument for why you would want to publish such information in the WSDL in the first place?

Consider the scenario I believe this is intended for (as I said, I have missed most of this discussion so correct me if this is wrong) where a MyService 1.0 was published and an endpoint made available. Now I have added a new endpoint for MyService 1.1 and the messages are a bit different (let's say there are some extra elements - although why should this be the only case you cover? What if some elements were removed, renamed [although that could be added+removed I suppose]? Surely you should cover all possibilities if you cover the extra elements case?). Sorry, back to it... So a client which knows about MyService 1.1's WSDL connects to MyService 1.0 (how would this happen since the endpoint information is in the WSDL?). The client sends a message that contains extra elements. So you want to be able to configure 1.0 to say to ignore these elements? But what has that got to do with the API being published in the WSDL? Surely that functionality should is nothing to do with the client that has read the WSDL? It is a backend flag that would be set in a configuraiton file somewhere not published in the WSDL.

So the other side would be if the client was generated from the 1.0 WSDL and communicates with the 1.1 service. But then the message would be *missing* elements. There is no flag to handle this.

I'll have a gander through the back-issues of this thread tomorrow so I don't make a fool of myself (any further) before making any more comments.

Pete Hendry
Principal Engineer
Cape Clear Software Inc.

Pete Hendry wrote: 

	Is support for ignoreUnknowns going to be mandatory or optional? I'd personally like it to be optional (well, removed actually) as I see no good use for it (and wouldn't like to waste time implementing it unless a customer was demanding such a feature - which none has so far). The purpose of using a schema is to precisely define the message content expected and a document/literal service should always validate against its schema. This was really the point of using document/literal over rpc/encoded surely?
	
	I think other alternatives should be used for this like introducing an encoding that allows for unknown elements (an optional encoding). That surely was the purpose of being able to define different encodings was it not? It seems to me that WSDL has chosen to use Schema to define the content of messages but doesn't like that schema actually does define the precise content of messages. 
	
	With this in the spec we will no longer be able to use the term document/literal but will have to come up with something new like "document/relaxed-literal", "document/laid-back-literal", or perhaps "document/literal++" :-)
	
	As Arthur says below in point 3, you only cover one use-case. If a message is sent to an old version of a service and the message contains extra information, then only in some cases will this be a valid scenario since the extra data is likely to be important to the expected behaviour of the service with which the client is communicating. I see the use of ignoreUnknowns as very, very narrow and it should therefore be out of the core spec and added as some sort of optional extension in a separate spec of its own (like an encoding for example).
	
	I haven't actually been following this discussion up to now so am jumping in a bit cold so I apologize if I've missed the mark with my comments.
	
	Pete Hendry
	Principal Engineer
	Cape Clear Software Inc.
	
	Arthur Ryman wrote: 


		Paul, 
		
		1) I am very much in favour of the intention behind this proposal since this is a real customer problem. But we do need to look at the details. 
		
		2) Let me explain more. I am concerned that there is no normative description of what "ignoreUnknowns" means. I understand that there are algortihms and data binding implementations that exhibit this behavior, but they are proprietary. What assurance do we have that they will interoperate? For example, vendor A may be very lenient and accept some unknown content, while vendor B may reject it interpretting it as a schema violation. Pointing to implementations and conference papers is not good enough. That is the point of the SOAP encoding example. We owe it to the community to reference a normative spec that defines ignoreUnknowns. Is there one? The latest proposal talks about ignoreUnknowns but doesn't define it precisely. 
		
		3) You may be happy enough that old Web services don't break when they get unknown content, but that is just one use case. Yes, we are encroaching into the domain of semantics, but Web services are not an abstract exercise. They exist to implement semantics. Web services are more than just interface. Yes, WSDL should only describe interface. That should tell you this is a bigger problem and that WSDL alone can't solve it. We need a coordinated effort across all the aspects of Web services. I agree that WSDL 2.0 should at least enable versioning. But the current proposal goes too far by being part of the Core and by making this, IMHO non-normative, definition the default. Can't we at least induce the Schema WG to create a Note that applies to XSD 1.0? 
		
		4) As I said, I still don't see a normative definition of ignoreUnknowns that would ensure interoperability. 
		
		
		Arthur Ryman,
		Rational Desktop Tools Development
		
		phone: +1-905-413-3077, TL 969-3077
		assistant: +1-905-413-2411, TL 969-2411
		fax: +1-905-413-4920, TL 969-4920
		mobile: +1-416-939-5063, text: 4169395063@fido.ca
		intranet: http://labweb.torolab.ibm.com/DRY6/ 
		
		
		
		<paul.downey@bt.com> <mailto:paul.downey@bt.com>  
		Sent by: www-ws-desc-request@w3.org 

		07/07/2005 07:24 AM 

							To
			Arthur Ryman/Toronto/IBM@IBMCA, <www-ws-desc@w3.org> <mailto:www-ws-desc@w3.org>  	
				cc
			
			
				Subject
			RE: LC124	 

		
			
			

		


		
		Arthur,
		
		thanks for taking the time and trouble to discuss this issue 
		and in trying to gain a company position within IBM. 
		
		I'll try and answer the discussion points raised:
		
		1) Agreed, obviously! Enabling the description of Web 
		  services that evolve is likely to be our top reason to 
		  move towards using WSDL 2.0. 
		
		2) Agreed, in essence this is an XML Schema issue, hence our 
		  original efforts to engage the Schema WG in a joint Task Force 
		  for versioning. However, Web services has a strong and simple 
		  use case for evolution of messages and much of the current focus 
		  of work on versioning within XML Schema has been in gathering 
		  other use-cases targeted at XML Schema 1.1
		
		  The cautionary tale regarding SOAP encoding is a good example, 
		  however that was a far more radical change than this proposal
		  and predated the XML Schema Recommendation.
		  ignoreUnkowns allows continued use of a current schema processor 
		  for validation, whilst embodying current best practice exhibited 
		  by the more flexible data binding implementations.
		
		3) This is an interesting point, but one which does fall into the 
		  semantics of the additional content:
		
		  If a processor requires the additional content, or that additional
		  content changes the meaning of existing content, then it isn't
		  a backwards compatible change, and should be published as a new
		  message, operation, service, etc.
		
		  The boolean flag enables publishers to add and accept additional
		  content, or highlight that strict validation should be used to 
		  constrain the message contents. I'm not sure what more information
		  would be useful, without exposing 'semantics', something
		  we avoid in WSDL.
		
		4) Please see the latest proposals for text:
		  http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0097.html 
		
		
		Paul
		
		
		-----Original Message-----
		From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On Behalf Of Arthur Ryman
		Sent: 06 July 2005 23:33
		To: www-ws-desc@w3.org
		Subject: LC124
		
		
		
		I've been discussing LC124 with my colleagues and I thought I'd post an update in case we discuss this tomorrow. 
		
		1. In general, we agree the versioning is important, and we'd like the problem addressed. 
		2. We are concerned that this is really an XML Schema problem and that WSDL is probably not the right place to address it. There is work going on now in the Schema WG. There are several solutions being proposed and it would be premature for WSDL to adopt the validate-twice solution (although that is a strong contender). As a cautionary tale, the creative use of Schema with SOAP Encoding was cited. The schema didn't really describe the message. We don't want a repeat in WSDL 2.0. We are concerned about locking in a solution that may not agree with the direction of Schema. 
		3. The boolean nature of ignoreUnknowns is not very useful. In many scenarios, it is important to know if the unknown content is preserved (e.g. passed on) or even processed. 
		4. There is no normative document that describes the proposed processing algorithm. Who will write that? (pointing to conference papers is not adequate). The WSDL spec should only cite other specs for Core features. 
		
		I need more time to establish a company position since this is vacation season. I'll try to move this issue forward though. 
		
		
		Arthur Ryman,
		Rational Desktop Tools Development
		
		phone: +1-905-413-3077, TL 969-3077
		assistant: +1-905-413-2411, TL 969-2411
		fax: +1-905-413-4920, TL 969-4920
		mobile: +1-416-939-5063, text: 4169395063@fido.ca
		intranet: http://labweb.torolab.ibm.com/DRY6/

Received on Thursday, 7 July 2005 17:08:48 UTC