Re: [xliff] Conflicting requirements w.r.t. Modules vs Extensions

["Dr. David Filip" <David.Filip@ul.ie>]

Fredrik, this issue was not introduced by the recent ballots.

The issue is inherent to the modular design. We went for a modular design to be able to develop the standard more flexibly.

From the start we say, extensions must not compete with core and module features. So every time you add a module you are potentially making some previously valid extensions illegal. Working on the modules, we should try and engage with owners of affected extensions and owners of extensions should actively follow the standard's development to make sure that the module replacing their extension does what they need.

I do not think that it is a good idea to revisit the recent ballots, and the 1st two solutions you propose would require revising them (each one of them).

The solution I propose is the one that you do not list, i.e. no action.

The preservation requirements for module and extension are not wildly different. Implementers are not encouraged to serially kill extensions. The distinction is exactly as needed, we cannot guarantee survival of extensions, because we do not know what is in them, if they are mutually conflicting etc.

I do not see how extensions would not become illegal after a new module is introduced, just because they would have the same level of protection as modules. They are becoming illegal by competing for functionality not by different PR.

Technical mechanism how to tell modules from extensions is the current schema. Implementers will try to preserve both, modules and extensions indiscriminately, because they MUST preserve modules and SHOULD preserve extensions. If they feel like deleting something they will need to lookup the schema to see if they can. If they want to delete module data, they will need to start supporting the module to be able to use its specific deletion PRs.

There is another issue, the module owners (with the exception of yourself) did not add module specific PRs, so that modules are now indeed indelible, which is clearly sub-optimal.

Cheers

dF

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

mailto: david.filip@ul.ie

On Thu, Nov 29, 2012 at 11:07 AM, Estreen, Fredrik <Fredrik.Estreen@lionbridge.com> wrote:

Hi All,

 

Thinking about the impact of the two recent ballots on modules and extensions (preservation rules and allowed namespaces) I believe we have introduced a forward compatibility issue.

 

The current state is that we allow modules to use the namespaces of externally defined standard (OASIS or other). At the same time we have chosen to specify different preservation rules for extensions (SHOULD) and modules (MUST). Combined and with the fact that there is no mechanism an implementation could use to determine if an unknown namespace is a module or extension, except by looking at the specification and schema of a particular revision of the XLIFF standard, it will not be possible to make a revision of the specification that just add one or more new modules and allow implementations conforming to an earlier revision to comply with the new revision. This is a serious forward compatibility issue in my opinion.

 

I can see some solutions:

* Make the preservation rules for modules and extensions the same so that unknown modules can be handled like extensions.

* Make usage of a TC assigned namespace mandatory for modules so that implementations can look at it and determine the preservation rules that it must apply.

* Introduce a technical mechanism that allow modules to be identified as such regardless of namespace used

* Introduce a technical mechanism that allow extensions to be identified as such regardless of namespace used

 

I would strongly favor the first option as it is easy to implement and at the same time affords flexibility. The second would be relatively easy to implement but still slightly harder than the first without offering the same flexibility. The last two seem overly complex to me.

 

Regards,

Fredrik Estreen