RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - version attribute

[Yves Savourel <ysavourel@enlaso.com>]

Hi Fredrik, all,


My first concern is about the version value: It is currently defined as a fixed value in the schema of the core.
So whenever we publish a new version we must change the schema of the core, and therefore increment the core version too. That leads
to having tools not working with the new namespace URI just because the specification version has changed.

So I would propose to change the declaration of the version attribute to make it and unspecified xs:string in the schema and define
its value in the specification only.

Now, as for the different types of changes and how to address them. I think I agree with most of what you are saying Fredrik.

At the end it looks like if the schemas are independent and we don't have a fixed set of modules forced with one given specification
version, we can have a single specification document for a while.

Cheers,
-yves




regardless I think my concern lies with the way a tool will have to handle different

-----Original Message-----
From: Estreen, Fredrik [mailto:Fredrik.Estreen@lionbridge.com] 
Sent: Thursday, December 5, 2013 9:08 AM
To: Yves Savourel; xliff@lists.oasis-open.org
Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - version attribute

Hi Yves, all

From a technical perspective I don't think there is a difference. Nor that there is a difference between publishing as one document
or multiple documents. It might sound strange at first but I think that is the case. This is based on my possibly incorrect
assumption that a standard cannot be un-published. Once it is published as a standard it will exist as long as someone has a copy of
the normative document. It might be abandoned or updated or there might be a recommendation to not use it but the published version
will forever be a standard.

For the update case if we release 2.0 as a single document including foo-module-2.0 we could release a separate document with
foo-module-3.0 at any time. Version 2.0 of the module would still exist as a standard, there would just be a successor standard
published separately from the core. As there is no requirement to support any module at all, a tool is free to only support the core
plus the separately published version of the module. It could at its own choose to support both the 2.0 and the 3.0 version of the
module or none. I don't think there is a material change if we release core as one standard and the modules as separate standards.
There would still be both a 2.0 and a 3.0 version of the module that could both be used with the core. As they would use their
namespace as the version they could even co-exist in the same document. Not sure that the last point is desirable though.

For the removal case I don't think we can ever remove a module regardless of how it is published, we can declare it abandoned or
superseded. But the one we once published will still exist. So again same document or multiple documents make no technical
difference.

I think the main issue will arise when we want to make a revision of the core after we made a revision of one of the modules
separately. At that point we would likely have to remove that module completely from the core + modules document before it could be
published. At that point breaking all modules out might be a good thing to do. We have no language in the modules as to which
versions of XLIFF they apply to. I think this might be a bigger technical issue. If kept as one document it is apparent that they
are supposed to work with the core version they are published together with. If published separately it becomes a little harder, do
we want to lock the module to a specific set of supported core versions or leave it open (possibly with a bound like 2.x). If we
lock it we will need to release new versions of the modules when we release a new core so they can include that in the list of
supported core versions. This would allow a future version of XLIFF to not support a "removed" module by simply not updating that
module to include the new core as supported. But almost the same effect would happen if we published an updated core without that
module in the case of one document with both core and modules.

An official registry of modules could be the solution to the what module version is supported with what core version problem. So we
should probably include that if we start looking at a registry.

What OASIS rules say on this I don't know, but we should probably try to find out.

I feel that if possible we should avoid making such a drastic change like splitting the standard into many standards at this point.
It is more of an administrative problem than a technical or implementation problem. And it would probably delay the process quite a
bit. But if there are some OASIS rules that would make future progress very difficult it might be a price we should pay now rather
than forever later.

Regards,
Fredrik Estreen

> Hi Fredrik, all,
> 
> > I don't think we necessarily need to release a new version of the 
> > whole specification to add a new module, as long as it has a TC 
> > namespace, now that we have the URN matching rule and no explicit 
> > references from core to modules.
> 
> Indeed. If the new modules go in separate documents, then we should be
> ok: no changes on 2.0.
> 
> But if we do make a modification to one of the 2.0 modules, or remove one:
> the same questions remain. What will be the changes then?
> 
> 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
>