Re: [xliff] IDs - Optional attributes (E)

Thanks, Yves, I think I see a consensus looming..

I do not think that my argument is driven by using XLIFF as a processing format, rather by processing XLIFF as an interchange format, which are totally different things. And I believe that the TC agreed that 2.0 is a roundtrip exchange format rather the old fire and die interchange format, so having (relatively) stable (actually as stable as possible) ids for the whole roundtrip at least on the key structural elements seems desirable.

This said I would be happy with markers, <segment>, <unit>, <group>, and <file> ids being compulsory

while <note> and <ignorable> being optional.

Having marker ids always compulsory would simplify the current notation dependent constraints, also marker ids became critical after prohibiting metadata on segment.

Group ids can be optional if unit ids are required to be unique within file rather than parent, I do see this as an important interrelation with the issue *D*.

Cheers

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

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 9:51 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

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

---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

xliff message