Versions and Modules

[Yves Savourel <ysavourel@enlaso.com>]

Hi all,

Working on implementing 2.1 I'm running into a few questions regarding how tools should handle different/new versions of a module.
I know that so far we have only one potential new module and no existing one modified, but it may be wise to think about the
different scenarios now, so tools implemented today have the expected behavior when those scenarios will occur.

So here are a few questions (and my assumptions so far):


-- 1) Can a module of version N+X be in a document version N?

For example, can we have the ITS module (v2.1) in a 2.0 document?

My assumption is: YES

A process may get for example a 2.0 document from tool T1 and use a tool T2 that adds some ITS annotations defined for 2.1. As long
as the 2.1 module is located in extensions points, the 2.0 tool would see that module as an un-supported module, while any 2.1 tool
supporting it would see it as a module.

If the 2.1 module has attributes or elements in places where there is no extension point... We have a problem. Because the 2.0 tools
cannot see those as valid (they are neither a module, nor an extension). --> Going forward we cannot add a module's attributes or
elements in other places than the extension points. At least not without breaking backward compatibility.


-- 2) Can we have two versions of the same module in the same document?

My assumption is: YES

We don't have this case yet, but since two versions of the same module would have a different namespace URI there is no technical
problem at having two (or more of them) in the same document.

If a tool supporting that module sees such thing it would simply use the version it supports and treat the others as un-supported
modules.



-- 3) What a tool is supposed to do when it supports a module version N and finds the same module in version N-X?

My assumption is: I don't know.

I don't think you can force a tool that supports module XYZ for version N to also support all previous versions of that module. At
the same time I don't think we can forbid a tool to do that either.

So the result may depend on whether or not the tool supports older versions of the module. If it does not the module is treated like
any un-supported module.



On other thing where I'm a bit unclear is the version numbers.

If we just add a new module, should we really move to 2.1? Isn't it more like 2.0.1?
As soon as the core namespace schema has to change we have to change its URI version too. But when you do this you break backward
compatibility, so shouldn't then the new spec version be 3.0 then (with a 2.1 version in the core URN?)
And if the spec version has no relation whatsoever with the versions of the namespaces, why don't we start the URN version of the
ITS module at 1.0?

Cheers,
-ys