[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] IDs - uniquness per type of element (C)
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?
Since there was no dissent on this one since Oct 22, I assume that this can be implemented
On Tue, Oct 22, 2013 at 6:42 PM, Yves Savourel <firstname.lastname@example.org> wrote:
Hi David, all,
> 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: