RE: [xliff-inline] Inline spans

[Yves Savourel <ysavourel@translate.com>]

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