OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xliff] RE: fragid in mtc


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 





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]