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 - unit id unique per file (D - 109)

OK, I gather that the TC wants unit id's unique per file and group ids should remain optional.
I am going to implement this but will roll back if I hear dissent by next Wed, Nov 13, 13,

Dr. David Filip
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie

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

> *D)*
> While it is quite clear that inline ids uniqueness scope needs to be
> <unit> and not <segment>. There is a similar issue on the <group>/<file>
> level but the pros and cons do not seem to be that clear.
> Yves requested that unit ids are unique within a <file> element rather
> than within the parent element, which obviously can be a <group>.
> *Proposed solution:*
> Do not change this, as unit id uniqueness within the parent element
> seems sufficient and in line with the design principle of requiring
> the smallest necessary uniqueness scope. Again, this is streaming friendly
> and makes groups full fledged grouping/structuring mechanism as intended.

I can tell you already that, as the submitter of 109, such "solution" would not resolve my comment.

I'm not following your arguments:

- I don't know where you get the idea that the TC has a "design principle of requiring the smallest necessary uniqueness scope". ->
Not a valid argument for keeping things as they are.

- Uniqueness of unit id within the parent is no more streaming-friendly than uniqueness within a file, as a group can span many
units and even the whole file. -> Not a valid argument for keeping things as they are.

- If the unit ids are unique within each <file> they are also unique within each group. So I don't see how that would impact
negatively making "groups full fledged grouping/structuring mechanism" (whatever that means).

In addition:

- Since your solution allows duplicates across groups, there has to be some benefits to that vs. not allowing duplicates. What are
those benefits?

- I don't think "id uniqueness within the parent element seems sufficient" is fine: Comment 109 gives an example showing that it is
not sufficient, and I guess I'll add a few more arguments:

a) In general IDs should be as unique as possible. XLIFF does not do this in some cases for good reasons. But the burden should be
on demonstrating that having no-uniqueness on a given scope is necessary, not the other way around.

b) Units are one of the basic objects in any localization tool. The capability to identify uniquely each one within a file in XLIFF
would make so many things simpler: e.g. pointing to the unit that has an error, using the unit id as index, etc.


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]