Re: LC124

Thanks for the clarification Paul. However, I remain unconvinced that 
this is the way to do it.

The problem, as you say, is the client's expectations. I propose it is 
therefore a function of the service to meet the client's expectations, 
not of the client to work with data it didn't expect. For the service to 
do that it must have some information from the client as to which 
version of the response it expects.

Achieving this by the proposed means of turning off schema validation 
seems a severe approach. What about a different approach of defining a 
standard "version" SOAP header? This would be defined in the WSDL as a 
"version" attribute in the descriptions element. The requirement the 
WSDL specification would place on the use of this version attribute 
would be that the client would have to insert a "wsdl:version" SOAP 
header with the version value in it and a mustUnderstand="1". I guess 
this should be phrased in a different way. There could be a standard 
WSDL version attribute and as part of the SOAP binding this attribute 
could be mapped to a SOAP header block.

The onus is then on the service to provide a response that is compatible 
with the said version, and so falls back on the framework/toolkit 
hosting the service to provide this functionality. The WSDL 
specification is then only defining a version attribute and specifying 
how it must be placed in the message. What the service does with this 
may not be a function of the wsdl specification - it is merely a hint 
possibly. Options would of course be to ignore it (and so risk returning 
an invalid response from the client's perspective and having the client 
fail), fault if the version is not supported, or send back a message 
compatible with the version specified.

Currently there is no indication other than the schema components 
themselves about what version of a service a particular endpoint is 
implementing (assuming endpoint URIs themselves convey no meaning), A 
version attribute would make this explicit.

A side issue that the version attribute also solves is where a client 
has been generated and is in use. How is the company that generated that 
client to know when the service has been updated? Currently I guess the 
only way would be to compare the current WSDL with the one from which 
the client was generated. I doubt anybody implements such an approach 
currently. Instead, having the ability to get the client to check the 
version flag and optionally report that the version has changed would be 
a way around this problem.

Pete

paul.downey@bt.com wrote:

>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 Friday, 8 July 2005 04:57:27 UTC