Re: LC124 - Support of evolution of messages described in Schema 1.0

Paul,

Thx for the recap.

I am concerned about the informality of your evolution rules. XML Schema 
is an incredibly complex spec. My concern is that it is not obvious that 
there is always a unique way to throw away unexpected content in order to 
obtain a valid message. This concerns me because it could lead to 
interoperability problems, i.e. a C# client doing something different than 
a Java client.

As I pointed out, the V2S schema makes assumptions that the added elements 
are not part of a known schema. We need to nail down the restrictions.

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> 
Sent by: www-ws-desc-request@w3.org
07/15/2005 12:56 PM

To
<www-ws-desc@w3.org>
cc

Subject
LC124 - Support of evolution of messages described in Schema 1.0







Ahead of next week's F2F here's my best understanding of  the current 
state 
of proposals and discussion for LC124.
 
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC124



** Description and Justification **

Original Proposal (Paul):
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0012

In essence, there is no way to describe the common and natural
evolution of an XML structure using XML Schema 1.0, eg.:

v1:

  <customer>
                 <firstName>Paul</firstName>
  </customer>

v2:

  <customer>
                 <firstName>Paul</firstName>
                 <lastName>Downey</lastName>
  </customer>

v3:

  <customer>
                 <firstName>Paul</firstName>
                 <lastName>Downey</lastName>
                 <middleName>Sumner</middleName>
  </customer>

whereby a format may evolve remaining backwards compatible following
three simple rules:

                 - make additional items optional
                 - don't delete items
                 - don't change the meaning of existing items




** Proposed Text **

Latest evolution (Jonathan):
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0091

"""
The "ignoreUnknown" property set to "true" denotes that the service 
accepts without faulting additional _unexpected items_ in messages sent to 
that service.  _Unexpected items_ are attributes and elements not defined 
by the schema for a particular element in the input message.  _Unexpected 
items_ may appear in any namespace including the targetNamespace of a 
known schema, as well as in a namespace for which no schema is currently 
known.  _Unexpected items_ includes the descendents of the item, such any 
child elements, attributes and content. 

Note: one mechanism for accomplishing this is to validate a message after 
content that is not known has been removed.  The unknown content may be 
identified by a W3C XML Schema processor.  The [validity] property in the 
Post Schema-Validation Infoset will contain a "notKnown" value if unknown 
content is found.
"""

The same assertion, or a parallel one should denote that the service is 
liable to insert unexpected items in messages it emits which a client 
should accept.


resulting from text from DaveO:
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0083

and Paul:
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0036




** Proposed Syntax **

There is uniform agreement that a ignoreUnknown flag would be required to 
control this feature, true meaning ignoreUnknowns, false meaning strict 
validation
applies. 

Options for syntax:
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0097.html



** Discussion **

Berlin F2F, 1 June 2005, overview of issue:
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/att-0002/20050601-ws-desc-minutes.html#item11


Telcon 9 June 2005, agreed not to close with no action:
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/att-0015/20050609-ws-desc-minutes.html#item06


Telcon 16 June 2005, validate twice and IP:
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/att-0059/20050616-ws-desc-minutes.html#item09


W3C Workshop on XML Schema 1.0 User Experiences, 22 June 2005:
Slides (Paul):
http://www.w3.org/2005/06/22-schema-workshop/LC124/slides.html

Minutes:
http://www.w3.org/2005/06/22-xsd-user-minutes.html#item03

Chairs' summary report:
http://www.w3.org/2005/06/21-schema-workshop/chairs-report.html#Versioning

Telcon 23 June 2005, feedback from workshop:
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/att-0085/20050623-ws-desc-minutes.html#item04


Telcon 30 June 2005, syntax, precedence of flag on types and endpoint:
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/att-0015/20050630-ws-desc-minutes.html#item04 




** Some Mailing List Concerns **

That unknowns might be ambiguous (Jonathan):
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0039.html
 
You have to be able to write a schema which describes the V2
and V1 messages, UPA actually helps here (Paul):
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0055.html

Lack of formal text to cite (Arthur):
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0026.html

Similar issues as with SOAP Encoding (Arthur):
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0019.html

But you can still validate (Paul):
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0057

psvi:notKnown != unknown (Arthur):
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0044.html
Explanation (Sandy Gao):
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0050.html

Problems with ignoreUnknows (soap Headers and body element) (Amy):
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0007.html

Attempt at a reply (Paul):
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0009.html

Evolution is a narrow use-case (Arthur, Umit and Pete Hendry (Cape))
various emails, refuted by Paul :-)

--
Paul