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

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


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