Subject: Re: [xliff] IDs - Optional attributes (E)
Hi David, all,
If you mean the <mrk> an <sm> elements by markers, they already have required IDs.
> 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.
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
> 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*.
ids unique per file is needed,
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
"Original resource - a IRI identifying the original resource from which the content of the <file> element is extracted."
So we would have:
- Required id on: <segment> (changed from optional)
- Optional id on: <group>, <note>, <ignorable> (no change)
- No id on <file> (changed from optional)
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.
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: