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

["Estreen, Fredrik" <Fredrik.Estreen@lionbridge.com>]

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
>