Conflicting requirements w.r.t. Modules vs Extensions

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

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