Namespaces, URIs, Versions, Versioning of schemas for signals and core: IMPLEMENTERS comments sought

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

Monica asked me to outline some options we have for the final decisions about namespace values. Because this is always complicated, I will also list some issues that underly options we have.

 

Both the core and signal schema files need namespaces. Namespaces are ‘declared’ by putting a URI in the targetNamespace attribute on a schema. The URI that is used for a namespace can also be one that is dereferencable (that is, the URL can be one that you can GET using a web agent to retrieve the schema data) The URI does not have to be dereferencable, and a schemaLocation attribute can contain a URL giving a location for the schema..

 

The specificationVersion is a number used in a BPSS instance to indicate the specification level for this TC’s ebxml-bp’s specification. The identifier used on the specification document (the “artifact”) can be the same as the specificationVersion but it does not have to be. That is, we can call the document 2.0.1 and it still be for the specificationVersion 2.0, for example. The schemas associated with a specificationVersion can have a namespace that incorporates the number of the version, a number of the document.

 

So here is one possible option:

 

specificationVersion == 2.0

document version for artifact name == 2.0.1

core Namespace (value of targetNamespace attribute)  == http://docs.oasis-open.org/ebxml-bp/ebbp-2.0

signal Namespace (value of targetNamespace attribute)   == http://docs.oasis-open.org/ebxml-bp/ebbp-signals-2.0

 

[Comment: We can have these URLs point to a schema document named, for example, http://docs.oasis-open.org/ebxml-bp/ebbp-signals-2.0.1a.xsd

and still have the namespace stay the same. A minor fix could then let us stay with the same namespace and specificationVersion but just correct some little schema glitch. The namespace URLs are, in effect, permanent URLs for the currently best available document Namespace URLs have specificationVersion information in them only

]

 

 

On this topic, there are many other ways to go. If you think we should not use the above schema, please post a concrete suggestion for a change and the reason for it to the list. We may need a preliminary vote on this issue before going to the public review. I think Monica has the “artifact” names and associated URLs fairly settled but the above issue was still open.