< Return to Ballot details

Vote Details

Ballot: Add "ref" attribute to "note" element
Company:
Trinity College Dublin (ADAPT)
Vote:
No
Comment:
Semantic core changes should not be made in a minor release, i.e. 2.2. This breaks the promise the TC gave the implementer community and industry at large.. when developing and releasing 2.0.

The proposed functionality exists in core, in case the implementer doesn't like the need of annotations, they can use a module or custom namespace from the core note, which is an extension point.

If you want to play with core, create XLIFF 3.0 backlog.

This is a breaking change, is not well designed or thought through. The functionality should be first tested as an extension, then perhaps promoted to a module in a 2.x release and perhaps some day to graduate to core in a 3.x release

If the ref is allowed, what are the admissible values, what can be referenced? Only segments, inlines?, can it be used from an arbitrary level, is it even restricted to segments or units? The core note simply applies to all payload at its given level, either source or target or both. This meddles with the clear semantics and provides a breaks the principle that there should be only one way to do things.

The clean design of 2.x core notes would be destroyed by this ill conceived change..

BTW, this also breaks the ITS 2.0 mapping (XLIFF 2.1 module) that works with the core notion of notes and their scope..