RE: [ws-rx] namespace URI versioning policy

["Yalcinalp, Umit" <umit.yalcinalp@sap.com>]

+1 

> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> Sent: Monday, Sep 19, 2005 5:32 PM
> To: ws-rx@lists.oasis-open.org
> Subject: [ws-rx] 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/act
ion_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.
>