RE: [xliff] RE: fragid in mtc

[Yves Savourel <ysavourel@enlaso.com>]

Hi all,

I think we have three options for the extensions/modules cases in the fragment identifier mechanism:


--- 1) Same as now.

When elements within an extension/module belong to another namespace they cannot be accessed.
That is the current situation.
It's not a very comprehensive solution, but we know it works.

Change needed: no implementation change, just add text to the specification stating the limitation.


--- 2) Extensions/modules can be containers of other extension/modules.

This option would allow extensions/modules to be containers of other extensions/modules, but have no special case for XLIFF core.
The core elements would be denoted with an 'xlf' prefix and work like the other extensions/modules.

We would have a provision in the section 4.9.2 (constraints of extensions) saying that the PR about ID uniqueness scope for the
extensions/modules has a special case: if the extension/module uses elements from the core namespace, the uniqueness requirements
are the one of the core (namely ID in source/target matching inline code should be the same), and fragment identification for those
elements is limited to the first id found.

So ref="#f=f1/u=u1/mtc=match1/t=mrk1" would not be valid, you could only do ref="#f=f1/u=u1/mtc=match1/xlf==mrk1" and access only
the first element with id='mrk1', so the source one if it exists in both source and target.

It's less limitative than solution #1. But it does not require a core-only implementation to know anything special about the
extensions/modules. I think it can be implemented. But we would have to be sure. The implementation requires to be able to know if a
core element is inside an extension/module and outside.

Change needed:

- Add a text like this is section 4.9.2:

[[
If the extension uses elements of the core, the id requirements for that part of the extension are the one of the core. For example,
one inline element in <xlf:source> can have the same id as its corresponding element in the <xlf:target> element). 
]]

- change the constraints of section 3 from:

[[
- There MUST NOT be two identical prefixes in the expression.
- When used, the following selectors MUST be declared in this order: file selector, group selector and
unit selector.
- The selectors for modules or extensions, <note>, <segment> or <ignorable> or source inline
elements, target inline elements and <data> have the following constraints:
  - Only one of them MAY be used in the expression.
  - The one used MUST be the last selector of the expression.
]]

To:

[[
- There MUST NOT be two identical prefixes in the expression, except for prefixes of module or extension which can occur multiple
times.
- When used, the following selectors MUST be declared in this order: file selector, group selector and
unit selector.
- The selectors for <note>, <segment> or <ignorable> or source inline
elements, target inline elements and <data> have the following constraints:
  - Only one of them MAY be used in the expression.
  - If one is used it MUST be the last selector of the expression.
]]

- Add the following text to section 3.2:

[[
- When used within an extension or a module, the elements of the core namespace are only accessible like any other module or
extension. The prefix of the core namespace "urn:oasis:names:tc:xliff:document:2.0" is 'xlf'. Because several elements of the core
may have the same id value, an agent MUST match the id of the core module to the first occurrence it find. For example if the id
"m1" exists in both the <xlf:source> and <xlf:target> elements of a <mtc:match id="1"> element, the expression "#mtc=1/xlf=m1" MUST
match the inline element in the source.
]]


--- 3) Any namespace within an extension/module element is accessible, including the XLIFF core elements as defined.

For example you could do: ref="#f=f1/u=u1/mtc=match1/t=mrk1" to access an core <mrk> element inside a <mtc:match> element.
You could do also much more complex references like ref="f=f1/u=u1/ext1=x1/ext2=x2/g=g1/u=u2/mtc=match1" etc. because after all,
nothing prevent an extension or future module to use any level of the core.

This is the most complete solution. But I don't think it is really implementable. I don't think you can ask an implementation not
supporting a given extension/module to work properly for XLIFF core elements within that extension/module. In other words, the
latter expression above would be resolvable only for implementations supporting the Translation Candidates module (mtc).

The reason is that if you don't support a given extension/module you can only be expected to treat that extension/module in a
generic way to make sure it survives a round-trip.

Note also that over time, we may end up with modules/extension that use core elements 2.0 while the core has move to a new version
(if the elements used in the module have not changed there is no reason for that module to change the core namespace it uses). So we
can't expect a core-only tool to deal with that.

Personally I would go for solution #2. It allows us to move forward with PRD03, get implementations during the comments period, and
either go back to #1 or keep #2 depending on whether or not we were able to implement #2.


Cheers,
-yves