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: Re: [ws-rx] namespace URI versioning policy


Peter,

To your question, yes. I suppose it could be clarified to indicate that 
other facets could be changed
in backwards compatible manner.

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

Peter Niblett <peter_niblett@uk.ibm.com> wrote on 09/20/2005 06:32:48 PM:

> Looks good to me
> 
> Is it the intention that "backwards compatible" between version n and 
n+1
> means that any message exchange or schema element instance that is
> validated by the version n WSDL/schema MUST also validate as ok with the
> version n+1 WSDL/schema?
> 
> I realise that the * list is just a set of examples, but I'm curious 
about
> why you mention just the pattern facet. Presumably you would be allowed 
to
> relax other facets such as length or maxExclusive
> 
> Peter Niblett
> IBM Senior Technical Staff Member
> 
> 
> 
>  
>              Christopher B  
>              Ferris  
>              <chrisfer@us.ibm. To 
>              com>                      ws-rx@lists.oasis-open.org  
> cc 
>              20/09/2005 01:32  
> 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/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]