Hello all,
I have taken ownership of all csprd02 comments that are affected by our global solution for ID uniqueness.
There is a long standing consensus in this TC that XLIFF ids cannot be of the xsd type XML id for several good business reasons
1) duplicity of id between source and target is being used as indicating the sameness of the element in source and target
2) XLIFF files can be huge and strict enforcement of uniqueness would prevent streamed handling of XLIFFs
For these and other reasons, all XLIFF ids are of the xsd type NMTOKEN and their uniqueness and usability is governed by Constraints and Processing Requirements.
Our second public review revealed that the uniqueness scope, constraints, and PRs need some fleshing out and probably even some material changes in the way how we go about uniqueness of ids.
The current deficiencies:
*A)*
Uniqueness of inline used ids is currently only enforced within a segment, which is clearly wrong and there is an easy fix.
*Proposed Solution: Enforce inline id uniqueness within <unit>*
*B)*
The current uniqueness Constraints ignore the fact that ids are in fact expected to be duplicated between <source> and <target> to signify the sameness of the elements between <source> and <target>.
*Proposed Solution: Add this exception to the relevant uniqueness constraints*
*C)*
Although this is not explicitly stated anywhere in the spec it is clear from examples etc. that ids are expected to be unique only for certain elements within the given scope.
For example, there is a tacit assumption that there can be a marker AND a segment with id="1" within the same <unit>
Possible solutions:
1. Kill this silent assumption and make clear that ids MUST be really unique within the given scope disregarding on what element they are specified.
This would not mean a big implementation burden. In the above example the segment could be id="s1" and the marker be id="m1". Any ref within the scope would be able to simply point like this ref="#s1" or ref="#m1" w/o the need to specify ref type or introducing a custom type for pointing within a specific element subscope.
Pros: Makes addresability easier. refs within scope can be of the type URI or IRI w/o further issues
Cons: This goes against a long standing assumption/tribal knowledge that is the harder to kill because it was never explicitly stated
2. Make this assumption explicit in the constraints related to ids. Have different ref types for ids on different elements or devise an adhoc referencing mechanism such as indicating the type ref or including the element info in the ref type.
Pros: Less changes, the long standing assumption is preserved
Cons: Awkward referencing from modules etc. refs of the type IRI or URI would not work w/o specifying type sperately.
*Proposed solution: 1.*
Other pending issues
*D)*
While it is quite clear that inline ids uniqueness scope needs to be <unit> and not <segment>. There is a similar issue on the <group>/<file> level but the pros and cons do not seem to be that clear.
Yves requested that unit ids are unique within a <file> element rather than within the parent element, which obviously can be a <group>.
*Proposed solution:*
Do not change this, as unit id uniqueness within the parent element seems sufficient and inline with the design principle of requiring the smallest necessary uniqueness scope. Again, this is streaming friendly and makes groups full fledged grouping/structuring mechanism as intended.
*E)*
Value of optional id attributes is questionable
*Proposed change:*
Depending on the resolution of D above, make all ids required. Complementary kill ids where they seem to be optional.
I believe that the above issues A, B, C, D, and E, need to be resolved on the general level to devise detailed solutions for each of the comments
Feel free to start separate discussions on any of the A, B, C, D, E, I just wanted to initially state the issues together to show their interdependence.
Thanks for your attention and consideration
dF
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734