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] IDs - uniquness per type of element (C)

Hi David,


I think there was no dissent on having inline codes and annotations be unique within the unit.


But I think the case of segment is still not resolved: Fredrik was still discussing this at this week’s call. And we didn’t have a conclusion on this as the discussion derived to translate being useful or not on segment and about ignorable.


At this point I don’t think we’ve resolved yet how to point to the content of a segment: by using the segment ID or by using a mrk enclosing the whole segment content?






From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: Friday, November 8, 2013 6:04 AM
To: Yves Savourel
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] IDs - uniquness per type of element (C)


Since there was no dissent on this one since Oct 22, I assume that this can be implemented

Dr. David Filip



University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734


On Tue, Oct 22, 2013 at 6:42 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi David, all,

> *C)*
> Although this is not explicitly stated anywhere in the spec it
> is clear from examples etc. that ids are expected to be unique only
> for certain elements within the given scope.
> For example, there is a tacit assumption that there can be a marker
> AND a segment with id="1" within the same <unit>
> Possible solutions:
> 1. Kill this silent assumption and make clear that ids MUST be really
> unique within the given scope disregarding on what element they
> are specified.
> This would not mean a big implementation burden. In the above example
> the segment could be id="s1" and the marker be id="m1". Any ref within the
> scope would be able to simply point like this ref="#s1" or ref="#m1" w/o
> the need to specify ref type or introducing a custom type for pointing
> within a specific element subscope.
> Pros: Makes addresability easier. refs within scope can be of the type
> URI or IRI w/o further issues
> Cons: This goes against a long standing assumption/tribal knowledge that
> is the harder to kill because it was never explicitly stated
> ...
> *Proposed solution: 1.*

+1 to option #1.

<segment>, <ignorable>, <mrk>/<sm>, <ph>, <pc>/<sm>/<em> must have unique ID within their <unit>.

Note that the matches modules may add inline codes and annotation within the same <unit>. But this is out of the scope of the core
constraints. (And I don't think we need to have a note about that).


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:


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