[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: XLIFF 2.0 proposal: Allow <note> to reference <mrk>
Good point, it may not be appropriate to overload the mid attribute if it is that strongly coupled to the segments.
In that case I agree that introducing a generic idref attribute on the <mrk> element may be better. If we keep it generic and don’t tie it to a specific element /attribute it would also open up other interesting possibilities for usage.
One such interesting option would be the ability to express various types of translation status information for segments. This could help us address the fact that many properties that would be useful on segment level are at the moment only available at the trans-unit level.
Very nice. I like this architecture.
One small matter though; I wonder if we might need a new attribute to use instead of mid. The way you're using the mid attribute in <mrk> in conjunction with the id attribute in <note> is more of an id/idref pair. In order to support your vision that a single note can reference multiple markers (taking into account your comment at the meeting that this could include markers from other trans-units, which appeals to me) we'd need to modify mid's keyref on target/mrk elements. In its current state, a target/mrk/@mid must have a corresponding seg-source/mrk/@mid (unique key).
If I wanted to refer to the same note to indicate another contextually inappropriate translation, in another trans-unit, by referring to note's id in a separate <mrk> mid, like this
<!-- another trans-unit elsewhere in the same XLIFF file as your example -->
. . . the parser would not find the "note1" key.
Doug might be able to adapt target/mrk/@mid to work in either case. But perhaps rather than changing mid to accommodate the new purpose, I wonder if it would be better to add a new idref attribute, like midref. Just my first impression. Otherwise I really like this approach.