OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: namespace URI versioning policy


All,

Fulfilling my AI [1], I have worked with Paul C to develop a namespace URI 
versioning
policy for our specs. (below)

Have at it!

Paul raised one point not addressed in the policy below. The W3C has a 
policy of making
a spec available at a "latest" URI that is fixed for the lifetime of a 
spec (well, mostly... rules
were made to be broken). The policy below doesn't provide such a feature. 

However, we could establish a policy that we could make the RDDLs 
available via
redirect or some equivalent means at the following URI:

        http://docs.oasis-open.org/wsrm/
        http://docs.oasis-open.org/wsrmp/

that would provide a means for developers to be able to always find the 
latest spec, 
schema and WSDLs, etc.

[1] 
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1004

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

Namespace Versioning Policy

The following is the declared policy of this specification with regards to 
the namespace URI assignment
for both the related XML Schema and WSDL definitions.

The pattern of the namespace URI shall be: 
http://docs.oasis-open.org/[product]/yyyymm/
Where [product] is the short name of the specification as prescribed by 
OASIS followed by
the century, year and month chosen by the TC. 

It is the intent of the WS-RX TC members that the namespace URI will not 
change arbitrarily
with each subsequent revision of the corresponding WSDL or XML Schema 
document, but rather
change only when a subsequent revision, published in conjunction with a 
Committee Specification
results in non-backwardly compatible changes from a previously published 
Committee Specification. 

Under this policy, the following are examples of backwards compatible 
changes that would
not result in assignment of a new namespace URI:

* addition of new global element, attribute, complexType and simpleType 
definitions
* addition of new operations within a WSDL portType or binding (along with 
the corresponding
  schema, message and part 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 
preponderance of instance would
  remain valid
* modifications to the cardinality of elements 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

The policy for namesapce URI assignment between subsequent revisions of TC 
editors drafts
shall be to retain the same namespace URI regardless of the nature of the 
changes. Prior to
adoption of a new Committee Specification, the TC will assess the 
backwards-compatibility
of the schema and WSDL documents with the prior Committee Specification 
(if any) and either
retain the namespace URI or assign a new one in accordance with this 
policy.

An RDDL document shall be made available at the namespace URI location 
that will provide
a link to the actual location of the relevant XML Schema or WSDL 
definitions documents. When
appropriate, the RDDL will provide links to the deprecated revisions of 
the XML Schema and
WSDL definitions documents that carry the same namespace URI.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]