RE: [xliff-inline] Inline spans

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

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