W3C home > Mailing lists > Public > public-ws-addressing@w3.org > May 2007

RE: NEW Issue - Need a new WS-Addressing metadata namespace

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>
Message-Id: <1179171852.3900.28.camel@localhost>

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.

Received on Monday, 14 May 2007 19:44:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:16 UTC