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:


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:

Sent by:

07/07/2005 07:24 AM

Arthur Ryman/Toronto/IBM@IBMCA, <>

RE: LC124


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:


-----Original Message-----
From: []On Behalf Of Arthur Ryman
Sent: 06 July 2005 23:33
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: