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

Thanks, Yves, inline..

Apart from the issues discussed below, I noticed a potentially suspicious discrepancy..

While there is an optional id attribute on <ec> there is no id attribute on <em>, is there a reason for handling them differently? I guess it is because original codes can be orphaned in the sense that there is no corresponding start code anywhere in the scope, right? Whereas this is considered impossible for annotations?

Just double checking that this was the intention of the Inline SC..

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 Wed, Oct 23, 2013 at 12:44 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi David, all,

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

If you mean the <mrk> an <sm> elements by markers, they already have required IDs.

I see the thing is that each of the annotation types lists the id as required separately, so I would drop these requirements in the annotations section as it seems confusing, probably as a result of marker ids being optional in a previous versions

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

I cannot see the relation between having unit ids unique per file and having id optional on groups, BUT since I do think having unit
ids unique per file is needed,

Let's keep this under *D*.

that makes my puzzlement moot and we don't have to discuss it.

That leaves <file>. And for that one I tend to think id is not needed. First there is the 'original' attribute that seems to fill
the same role (and is older: <file> has no id in 1.2). Also: several <file> elements can be moved to a single XLIFF documents, for
example when bundling a package. Several tools have even utilities to do this. In such case you may have clash of identical IDs and
you are left with two options: a) not bundle one of the <file> or b) change its ID value; none of which is really doable.

For <file> I would propose to drop the id attribute, and have original as the way to identify the resource corresponding to the
given <file> (which is already its role). I would also update the definition of 'original' from:

"Original file - a pointer to the location of the original document from which the content of the enclosing <file> element is
extracted."

To:

"Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted."

I agree with dropping id from file and with the changed original definition..

So we would have:

- Required id on: <segment> (changed from optional)

I agree

- Optional id on: <group>, <note>, <ignorable> (no change)
- No id on <file> (changed from optional)

I agree

BTW: One more correction for the spec: in the section 2.3.1 in the list of attribute the link on the 'original' attribute points to
the section for the 'name' attribute instead of the section for the 'original' attribute.

Thanks I will add this to comment #124

-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