RE: LC124

 

> -----Original Message-----
> From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org] On Behalf Of paul.downey@bt.com
> Sent: Thursday, Jul 07, 2005 10:09 AM
> To: peter.hendry@capeclear.com; www-ws-desc@w3.org
> Subject: 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.

Paul, 

As a vendor that considers web services interoperability a major
requirement and would like to see versioning problem to be solved
interoperably, we have concerns as to positioning the mustIgnores to be
the norm as the strong preference of the wg. In our opinion, this is one
dimension of versioning and there is no guarantee that the data binding
tools may interoperate since their choices are proprietary. Therefore,
we share the concerns that Arthur has been bringing up. 

 

> 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. 

In this case, we are talking about undeclared content, lets not conflate
the two concerns. 

> 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.

Unfortunately, best practices do not necessarily constitute formal specs
unless there is a clear semantics that is agreed upon between tool
vendors. In my opinion, this is emerging trend that will be present in
tomorrow's toolkits when it will start to be adopted in different
platfroms, but for today's toolkits which are in production, it will be
hard to say that we can standardize the behavior. 

To be clear, I do believe that versioning is a very important problem
and best practices will go along way for making WSDL authors to think
about the problem and adopt a set of guidelines. We made this point very
clear during the XML Schema users workshop. However, I am quite
concerned if ignoreUnknowns which is an XML Schema problem in the first
place, gets to be the norm in WSDL 2.0. This is why I advocated this to
be a predefined extension in WSDL 2.0 and its utility will be clearly
present in the markup when used. If that is not possible, I will be in
favor of making it NOT the default behavior, which will again require
clear designation in WSDL when utilized, but I am simply not in favor of
making this a default behavior. The new toolkits that support this
behavior can simply designate this semantic with a clear markup in WSDL.


WSDL 2.0 has come a long way. If we want adoption and implementations to
be emerging rapidly, incorporating an extended semantics of XML Schema
will make vendors to adopt WSDL 2.0 later, not sooner. This is raising a
bar which is not really appropriate as the default behavior. 
 
> 
> 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

Again, another indication that this problem can not be solved
interoperably yet within WSDL as it is a schema problem. 
 

>  
> Paul
> 
> 

Cheers, 

--umit

> -----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 19:23:53 UTC