- From: Philippe Le Hegaret <plh@w3.org>
- Date: Mon, 14 May 2007 19:44:11 +0000
- To: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
- Cc: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
On Mon, 2007-05-14 at 11:46 -0700, Ram Jeyaraman wrote: > Addendum to the proposed resolution: > > In addition to the proposed resolution, I suggest adding a section to > the proposed new namespace document as follows: This is a fine addition to have in our namespace documents as soon as those reaches CR, but in the meantime, the namespace will keep changing so I don't think it's an adequate addition at this point. > Stability of this namespace URI: > > It is the intent of the W3C Web Services Addressing Working Group that > the Web Services Addressing 1.0 Metadata XML namespace URI will not > change arbitrarily with each subsequent revision of the corresponding > XML Schema documents as the specifications transition through > Candidate Recommendation, Proposed Recommendation and Recommendation > status. However, should the specifications revert to Working Draft > status, and a subsequent revision, published as a WD, CR or PR draft, > results in non-backwardly compatible changes from a previously > published WD, CR or PR draft of the specification, the namespace URI > will be changed accordingly. > Under this policy, the following are examples of backwards compatible > changes that would not result in assignment of a new XML namespace > URI: > > * Addition of new global element, attribute, complexType and > simpleType definitions. > * Addition of new elements or attributes in locations covered by > a previously specified wildcard. > * Modifications to the pattern facet of a type definition for > which the value-space of the previous definition remains valid > or for which the value-space of the vast majority of instances > would remain valid. > * Modifications to the cardinality of elements (i.e. > modifications to minOccurs or maxOccurs attribute value of an > element declaration) for which the value-space of possible > instance documents conformant to the previous revision of the > schema would still be valid with regards to the revised > cardinality rule. I don't think we should define what is a backward compatible change or not. Those examples are based on changes in the XML Schema and aren't really representatives of changes that can occur in the entire document. I would also argue that adding complexType or simpleType definitions in the XML Schema isn't a non-backward compatible change in the specification, as long as we don't introduce new elements or attributes of course. So I'd suggest not including examples for non-backward compatible changes and judge on a case-by-case basis when necessary. Philippe
Received on Monday, 14 May 2007 19:44:38 UTC