Hi David, all,
>> In addition to <segment>, id is currently optional in:
>> <file>, <group>, <ignorable> and <note>.
>
> I believe that all of these should have either required id
> or no id at all.
> ...
> If the resolution for the issue *D* decides that unit ids need
> to be unique within file and not parent, than eventually group
> ids could become optional..
Why? I don't think the two issues/solutions are related.
When unit's ids are only unique per parent the tools needing unique values have to create their own but they don't need group ids
for that.
>> I think you also forgot to list the arguments supporting the statement
>> "Value of optional id attributes is questionable".
>
> I belive that it is questionable becuase you cannot rely on the id being
> there, so that you cannot count on referencing ids as a general implementation
> principle, referncing then seems only possible locally and not
> in e.g. DB representations..
That sounds like a processing-side argument :)
XLIFF is an interchange format: and nothing prevent an optional IDs to be there if it is needed.
Some implementation don't use IDs to associate (for example) a segment with a match, but they would generate the IDs on output (like
Okapi does). As for implementations that use IDs (like some DB-based one) nothing prevent them to create those id when they do their
processing (or when reading the document) and output them alter on.
Note that I'm not especially against a required id for <segment> (it can be used for many things), but as you can see in the
previous paragraph, the case for optional can be made even for <segment> (and the referencing still work).
So don't think it should be mandatory nor forbidden on <group>, <ignorable> and <note>.
Cheers,
-yves
