RE: [xliff-inline] Inline spans

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

Hi Yves,

To me the best part of your question is your clarifying statement that overlapping span of information is infrequent. Because the rest of it is a mind-bender.

I'll give my predictable pro-XML-friendly case. And then I'll prepare for the opposing opinions from the pragmatists.

Since this is *hopefully* an uber-fringe case. I my preference is for A). I know this is causes overhead for the processor and (in the cases where to processor has not shielded the translator) for the translator. But I fear a slippery slope if we (re)start using <begin /> and <end /> elements.

But I will not be stubborn - I understand the argument for B) as it favors readability. I guess on the plus side, I don't see any escaped XML in the B) example. :)

- Bryan

-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com] 
Sent: Friday, May 06, 2011 12:51 PM
To: xliff-inline@lists.oasis-open.org
Subject: [xliff-inline] Inline spans

Going back to the discussions about the <mrk>-types elements:

Klemens (who should be joining the TC/SC soon) had some interesting notes regarding the need to support overlapping spans.

Here is an example based on his example:

"This is a [[very {{simple]] and not very useful}} text"

We has some information attached to [[very simple]], e.g. marking it as a term.
We have also information attached to {{simple and not very useful}}, e.g. do-not-translate

I know overlapping span of information may not be very frequent, but they are perfectly possible and should be supported.
How do we go about representing this in XLIFF?

So far I see two solutions:


=== A) Using several elements:

"This is a <term>very <notrans>simple</notrans></term><notrans> and not very useful</notrans> text"

But while it may be ok in some cases like for a do-not-translate span, other type of information, like "term" should be provided with the proper unique span. This means the processing expectations for this type of elements would be to merge adjacent spans of the same types, maybe using some id. It makes things quite complicated.


=== B) Using start/end markers

Another way would be to not use span-like elements, but use empty elements denoting the start and the end of the spans:

"This is a <startTerm id='1'/>very <startNoTrans id='1'>simple<endTerm rid='1'/> and not very useful<endNoTrans rid='2'/> text"

This is obviously much less XML-friendly, but it's also a lot easier to parse when we read faced with segmented content.


Any thoughts?
-ys




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php