Provide a way to associate <note> elements with <segment> elements

[rmraya]

There should be a way to associate a <note> element with a given <segment>. The "ref" attribute from XLIFF core namespace could be used for that but needs to be added to <note> in the schema.

[DavidFatDavidF]

I strongly oppose changing the core schema. That would violate the agreed modularity principles that are behind XLIFF 2.x, that is its backwards and forwards compatibility.

It is by design that notes don't allow to be directly associated with segments in core, mainly for the following two reasons

1. segment ids are optional
2. segmentation is supposed to change, so there's a danger of creating orphaned references

Also there is another way in core to have notes associated with subunit spans It is through the comment type annotation http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html#commentAnnotation This method has the advantage that it is resilient to re-segmentation. Re-segmentation if done properly will not disrupt the annotation spans..

If you do not like the annotation way that requires use of marker spans (in order to be re-segmentation resilient) you can extend the core note by a private @ref in your own namespace After all is an attribute extension point.. http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html#note

[rmraya]

Hi,

I resolved my problem using @mtc:ref (“ref” attribute from matches module). Nevertheless, this is an awkward solution because notes belong to core, not matches.

Your objections are not valid. I know that segment ids are optional but you would have to use an id if you want to reference it. If segmentation changes, the process that modifies segmentations is responsible for adjusting the note accordingly, among other required changes, like adjusting matches and term references.

The comment annotation that you suggest works for pointing a note to a span that may live anywhere (even in a different unit), not for pointing a segment to a note. It does not solve the problem I tried to solve: collect all notes that belong to a given segment when the segment is selected for translating.

Using the core “ref” attribute should be available in notes, even for pointing to a text span. This way you solve the lack of bidirectional linking from the comment annotation.

Regards, Rodolfo

[DavidFatDavidF]

Rodolfo, u can of course use any non-core ref attribute in the note. That's what I suggested in case u don't like the core comment annotation solution. Obviously, mtc: doesn't have module status on the note; it is treated there as any other third party namespace.. Please note that the mtc:ref requires an IRI, so it has to use the fragid mechanism to point to the segment. Since u dislike the fragid mechanism, you would be probably better off with a private mechanism using directly the NMTOKEN of the target reference within the same unit.

My two points only explain why the core intentionally doesn't allow segment references. They were the reasons why the TC went for the existing design of the mechanism. Referencing of segments is generally not impossible in the spec but discouraged and made not preferable by design, especially not in the core that should be simple and resilient.

If your use case is collecting notes relevant for a segment, I think that the commenting mechanism works just great u can look for annotations of the type comment within that segment and this will either have a set value that u can use directly or will bring up a note within the parent unit.

Finally and related to the above point, it's not true that the comment annotation can be used to point to notes outside the unit. There is a specific constraint preventing exactly that

If the value attribute is present it contains the text of the comment. If and only if the value attribute is not present, the ref attribute MUST be present and contain the URI of a <note> element within the same enclosing <unit> element that holds the comment.

[DavidFatDavidF]

I suggest that this marked as wontfix and closed in the next XLIFF TC quorum meeting

[rmraya]

1. Email 21 sept 2021. https://lists.oasis-open.org/archives/xliff/202109/msg00002.html

Issue 4 was discussed in the meeting of the 21st of September. See meeting minutes. And it was agreed that a decision will be taken in the following official meeting (19 October). An announcement on the important of that meeting was included in the subject of the email and also on the body of the email. See https://lists.oasis-open.org/archives/xliff/202109/msg00002.html

2. Email from Bryan on the 5th Oct. He sent his regrets for the informative meeting on that day and expressed his opinion: “But for the sake of discussion, I have no problem doing the hard work of changing core, having a full version update, or splitting core and modules.”. https://lists.oasis-open.org/archives/xliff/202110/msg00001.html . Lucía answered him that the roll call vote will take place on the official meeting on the 19th. https://lists.oasis-open.org/archives/xliff/202110/msg00002.html

3. Meeting minutes from the 19th October. https://lists.oasis-open.org/archives/xliff/202110/msg00006.html Issue 4 was discussed again, a roll call with the following text ““Allow changes in the core schema to fix issues reported in GitHub even if that means changing version number.” Do you agree? “ was proposed. The ballot was approved.

[rmraya]

XLIFF TC approved adding "ref" attribute to <note> element on a formal ballot: https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=3690.