1.5. Must allow to associate spans of content with metadata

[Yves Savourel <ysavourel@enlaso.com>]

Hi everyone,

I'll try to summarize the results of the discussions we had about how to implement the different metadata/information such as comments, translate flag, term, etc.

(requirement #5 http://wiki.oasis-open.org/xliff/OneContentModel/Requirements#Mustallowtoassociatespansofcontentwithmetadata)


a) It seems the comments may be an important enough construct of XLIFF to have it defined outside of the inline markup, and use a simple pointer to it when it is applied to a span of content. This can be represented using the generic element.

b) It seems the generic element would be sufficient to handle both predefined metadata and tool-specific ones.

Such element (<mrk>) would look like this (again names are just temporary):

<mrk type='theType' [id='anId'] [ref='someId'] [value='stuff'] [translate='yes|no']>text</mrk>

Where:

'type' is a mandatory attribute to indicate the type of information applied.

'id' is an optional attribute to allow linking the marker in both the source and the target part of the entry. For example to link a source term and its translation. This attribute would be used only when such link would need to be represented.

'ref' is an optional attribute that would contain the ID of an element external to the content that would contain the actual data to apply to the span of marked content.

'value' is an optional attribute that would store the property value to apply to the span of content. This would be used for short tool-specific meta information that do not need to define a whole element.

'translate' (values 'yes' or 'no') is an optional attribute that would indicate if the span of content is translatable or not. It would be set to yes by default.


The pre-defined types would be:

--- 'term', with an optional ref pointing to an external element containing a block of additional terminology information.

This would map to the following ITS data category:

<its:termRule selector="//mrk[@type='term']" term="yes" termInfoPointer="id(@ref)"/>


--- 'comment', with a mandatory ref attribute pointing to an external comment element containing the comments and its metadata. The element would be defined by XLIFF and re-usable at the text unit and other levels.

<mrk type='comment' ref='myComment1'>...</mrk>

[[Addition from Yves, not discussed during the meeting: We could alternatively use the 'value' attribute instead of the ref attribute, and store a simple text comment. That may be a lighter way to implement comments for some tools.]]


Any comments, remark, use cases we've not thought about?

I'll try to implement this (or part of it) in the coming weeks to possibly catch some issue we are not seeing.


Cheers,
-ys