W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > February 2009

RE: Issue-6519 Alternative namespace change policy

From: Geoff Bullen <Geoff.Bullen@microsoft.com>
Date: Tue, 3 Feb 2009 12:51:19 -0800
To: Bob Freund <bob@freunds.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Message-ID: <5AAAA6322448AA41840FC4563A30D6E8427CABAC04@NA-EXMSG-C122.redmond.corp.microsoft.com>

Generally we think this looks OK, and we agree that there is little benefit in even implying that the namespace could be fixed before CR.

However, we are not clear on what the definition of "significant change" might be in last sentence below.  There seems to be quite a number of new features and proposals that are being suggested for these specifications and we believe that there is a high probability that issues will be found during the interop period, which occurs between CR and PR.

Perhaps we need to be more precise in our understanding of the types of changes that would be deemed "significant" and thus cause a namespace change after CR.  Can we incorporate some of the wording from the original proposal (or similar wording) to enhance this understanding?

We suggest something like...

The working group intends to update the value of the Web Services XXXX namespace URI each time a new version of this document is published until such time that the document reaches Candidate Recommendation status.  Once it has reached Candidate Recommendation status, the working group will not change the namespace arbitrarily with each subsequent revision of the corresponding XML Schema documents but rather change only when a subsequent revision results in non-backwardly compatible changes from a previously published revision.

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.

-----Original Message-----
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Bob Freund
Sent: Tuesday, February 03, 2009 11:17 AM
To: public-ws-resource-access@w3.org
Subject: Re: Issue-6519 Alternative namespace change policy

The proposal in the original issue requires a backwards compatibility
judgement call at each publication in order to determine if a
namespace change might be required.
Below is an alternative that causes the namespace to be changed at
each publication through CR

The working group intends to update the value of the Web Services XXXX
namespace URI each time a new version of this document is published
until such time that the document reaches Candidate Recommendation
status. Once it has reached Candidate Recommendation status, the
working group intends to maintain the value of the Web Services XXXX
namespace URI that was assigned in the Candidate Recommendation unless
significant changes are made that impact the implementation of the
specification.

Since CR is the point at which the call for implementations is issued,
there is no benefit to the WG to maintain a stable namespace until
that time.
-bob
Received on Tuesday, 3 February 2009 20:52:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:17:45 GMT