XLIFF Inline Markup SC

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

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

Hi Bryan, > To me the best part of your question is your clarifying > statement that overlapping span of information is infrequent. The problem is that some of those markers are placed by end-users (like comments) not tools, so there is no predictability associated with how frequent they would be. > 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. This would mean the different elements making up a single span would need so unique id associating them together, as just two elements of the same type may not mean a single span. Note that this complicate things for XSLT-based processor too, not just DOM/StaX based processor. > But I fear a slippery slope if we (re)start using > <begin /> and <end /> elements. I'm afraid there is no way to not provide those, as the root problem is a shortcoming of XML itself: it just does not handle overlapping spans well, and that is not an un-common type of construct in documents. Note also that such the issue is not only needed for overlapping spans, but also for spans cut by segment breaks. As a devil's advocate I'll say it: The question is going to keep coming: If we must provide a <start/>/<end/>-type of mechanism, it will be part of the constructs that all tools must understand. If all tools must understand that mechanism, why provide another one? -ys

Hi Yves,

Sorry to answer too late. But here are my thoughts. I am working up some actual examples and XSLTs to illustrate my opinions, but I'm not quite done with them yet. I'll send them shortly (or not at all if it is a moot point)


Original Message-----
From: Yves Savourel [ mailto:ysavourel@translate.com ]
Sent: Sunday, May 08, 2011 10:04 AM
To: xliff-inline@lists.oasis-open.org
Subject: RE: [xliff-inline] Inline spans

Hi Bryan,

> To me the best part of your question is your clarifying
> statement that overlapping span of information is infrequent.

The problem is that some of those markers are placed by end-users (like comments) not tools, so there is no predictability associated with how frequent they would be.


> 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.

This would mean the different elements making up a single span would need so unique id associating them together, as just two elements of the same type may not mean a single span.
{Schnabel: I agree, a complex solution for a complex problem}

Note that this complicate things for XSLT-based processor too, not just DOM/StaX based processor.
{Schnabel: I don't see it that way. I see different elements with unique id's way more XSLT and DOM friendly than <start/>/<end/>. I'll add an example at the end of this note}


> But I fear a slippery slope if we (re)start using
> <begin /> and <end /> elements.

I'm afraid there is no way to not provide those, as the root problem is a shortcoming of XML itself: it just does not handle overlapping spans well, and that is not an un-common type of construct in documents.
{Schnabel: Of the scenarios I've seen so far, I can think of ways of not using <begin /> and <end /> elements. XML representations of strange spans is not a new problem (nor would I say any more or less challenging by shortcomings of XML). Granted the representations do not always look pretty to the human eye, but they work for the processors.}

Note also that such the issue is not only needed for overlapping spans, but also for spans cut by segment breaks.

As a devil's advocate I'll say it: The question is going to keep coming: If we must provide a <start/>/<end/>-type of mechanism, it will be part of the constructs that all tools must understand. If all tools must understand that mechanism, why provide another one?

-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

> Sorry to answer too late. But here are my thoughts. > I am working up some actual examples and XSLTs to > illustrate my opinions, but I'm not quite done with > them yet. I'll send them shortly (or not at all if it is a moot point) It's not a moot point. We talked about the topic at the call and Andrew pointed out he was preferring the solution A (splitting the spans and reconstructing them) I'm still thinking splitting/rejoining spans is going to take a lot of effort. One of the arguments in favor of using span notation is "It's better XML". But I think it's a misleading argument: avoiding start/end markers because the XML handles span better is wrong. The real issue is that our requirement is to allow overlapping spans and XML cannot do that. XML is the problem here :) -ys