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 Yves,

If we keep the spanning inline codes like <pc> I'm firmly for the <sa>/<ea> style of annotations. Using spanning annotations and spanning inline codes would likely produce a lot of broken-up annotation spans.

If we do not have spanning inline codes I'm leaning towards spanning annotations as I find them more elegant and I expect the amount of collisions between annotations to be relatively infrequent. But I'm not sure about this yet.

Regards,
Fredrik Estreen 

-----Original Message-----
From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: den 28 oktober 2011 13:58
To: xliff-inline@lists.oasis-open.org
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.

Cheers,
-yves





---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org




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