[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] IDs - Optional attributes (E)
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.
> ...Why? I don't think the two issues/solutions are related.
> 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..
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
That sounds like a processing-side argument :)
>> 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..
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>.
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: