Re: [xliff] RE: fragid in mtc

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

All, I do not like 2) at all, it is too ad hoc.

1) and 3) are clear cut solutions.

I am not sure if I understand the issues that 3 supposedlz brings.

I believe that modules/extensions should be allowed to reuse any level of core if they need it.

I do not see why a core only processor should understand what they are doing with their own core subtree.

Also, I do not see why reusing a core subtree fragid encapsulated within a container module/extension is an issue. It would behave after all the same way as the core fragid.

Anyways, If everyone thinks that 3 is too complex, I would support 1 for the sake of moving forward with csprd03.

But there is also the issue of reuising mda, mda was supposed to be a generalized metadata mechanism, but if not fully accessible in modules, there seems to be not much advantage in allowing it at all..

Rgds

dF

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

http://www.cngl.ie/profile/?i=452

mailto: david.filip@ul.ie

On Mon, Jan 20, 2014 at 5:33 PM, Schnabel, Bryan S <bryan.s.schnabel@tektronix.com> wrote:

I agree the ---3) carries too much overhead.

I am working on implementing ---1) now and have pretty high confidence that I can support it. At first glance I think I can support ---2) as well (but I will need to code it to be sure).

So I would vote for 1, then 2, but not 3.

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel

Sent: Friday, January 17, 2014 4:42 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] RE: fragid in mtc

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



---------------------------------------------------------------------
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




---------------------------------------------------------------------
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