Re: [xliff] Versions and Modules

Thanks, Yves, my opinion inline..

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

I agree, although this seems counter intuitive at first the below reasoning makes sense

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.

Sure, we now that and we do not plan to add modules at new extension points, exactly because we do not want to break backwards compatibility.

It is good to be aware of this when designing any new modules. Anyways, if new modules were previously implemented as extensions. There is no real danger of pushing them onto a previously non-existent extension point..

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

My assumption is: YES

I agree

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.

Exactly

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 think no one can know, as there is no general answer to that.

This depends on the backwards comapatibilty of the new module version that needs to be specified by the creators of the new version.

It can even happen that the new version of a module deprecates previous versions. This would then modify answers to 2 and 1 as a special case. O the module creators can mandate supporting oler versions of the module. There is no way of knowing in advance.

I think something like this is about to happen very soon. In Dublin people complainer that ctr does not support inlines. So we'd be in for a 2.1 or 2.2 version for ctr. Now when it comes to the development the TC will need to discuss if the ctr 2.0 should be deprecated or if there is a way to make ctr 2.1 work with ctr 2.0

Deprecation would happen by moving the namespace to the listing of URN prefixes that are not XLIFF-defined. If the deprecated module still occurs it would not be protected as a module and a tool supporting the higher version could replace or remove it based on N's Processing Requirements. All other tools working with the document version N would see the deprecated N-x module, as an extension and not as a module and they would be entitled to get rid of it if it causes any trouble..

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.

As I said above it will fully depend on the provisions in the new module version

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?

We said in the approved and published Charter Clarification that new versions with added modules will be numbered 2.x and only possible minor bugfix releases will be called 2.x.y

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?)

Again, according to the Charter 3.0 is reserved for a major new release if we were not able to maintain 2.x compatibility due to major developments in the industry.

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?

I agree the relation is loose, but then all the modules that have been published with 2.0 could have been called 1.0 because previous versions of these namespaces did not exist.

Now, we didn't do that. And to avoid confusion, we should stick to the practice of numbering the module namespaces according to the first document version in which they were defined as a module. So 2.1 for ITS and 2.0 for all other currently available modules..

Cheers,
-ys

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

xliff message