OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-inline message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xliff-inline] 1.5. Must allow to associate spans of content with metadata

Hi all,

> <mrk type='theType' [id='anId'] [ref='someId'] [value='stuff']
> [translate='yes|no']>text</mrk>
> ...
> I'll try to implement this (or part of it) in the 
> coming weeks to possibly catch some issue we are 
> not seeing.

I've started to look at implementing this and run into one fundamental aspect we didn't discussed much lately: what to do when we have overlapping annotations/inline codes or annotations going across several segments?

For example:

Text <mrk type="some-type">in <pc id="1">bold</mrk> and italics</pc>.

Since we don't talked about placeholder-type elements for <mrk>, should we have the annotation take precedence over the code? and have:

Text <mrk type="some-type">in <sc id="1"/>bold</mrk> and italics<ec rid="1"/>

For the cases of overlapping annotations or annotation broken by segment break, a while back we said we would create new span of annotations. So something like:

Text <mrk type='sometype1'>with some <mrk type='sometype2'>important</mrk> meaning</mrk>.

Would be encoded:

Text <mrk type='sometype1'>with some </mrk><mrk type='sometype1'><mrk type='sometype2'>important</mrk></mrk><mrk type='sometype2'> meaning</mrk>.

This last solution is quite complicated to implement, especially if the processing expectation is to merge the similar info when reading the segment.

So, in the light of the <pc> vs <sc>/<ec> discussion, would it make sense for our annotations to favor a start/end elements model rather than a span-like model? That is, instead of having a <mrk> element, we would have two elements like <sa/> and <ea/> (start annotation/end annotation) with the same id/rid system as in <sc>/<ec>? Something like:

Text <sa id="1" type='sometype1'/>with some <sa id="2" type='sometype2'/>important<ea rid="1"/> meaning<ea rid="2"/>.

I suppose this would be consistent with the <sc>/<ec> pattern and avoid any overlapping/segmentation issues.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]