Storing native data

[Yves Savourel <ysavourel@translate.com>]

Hi everybody,

Just a note to remind you that everyone has the action item to think about how to store native data for our XLIFF inline codes...

Here are some general thoughts that may help the discussion:

We have currently three requirements to cover:

a) no storage of the native data
b) storage of the native data outside the inline code
c) storing the data along with the inline code

I'll talk only about c) since a) and b) are easy to do.
 
There are not many ways to store the native data along with its inline code representation. It can be either in some attributes or the content.

=== Storing in some attribute(s):

For example: <pc id='1' start='[data]' end='[/data]'>text</pc>

Pros:

- Avoid having mixed text nodes in XLIFF: all text nodes are real text. No guessing to do by looking at the parent: makes some processing a lot simpler.

Cons:

- preserving whitespaces may require some efforts


=== Storing as the content of the inline code:

For example: <sc id='1'>[data]</sc>text<ec id='1'>[/data]</ec>

Pros:

- Easy to store even large data chunks

- Easy to preserve whitespaces

- Provide automatically a way to handle overlapping codes, no need to have a different markup.

Cons:

- Introduces text nodes that are not text content

- Force to break the XML model: the content affected by the code is not its descendants anymore it's its siblings until the end-code element is reached.

- Forces use of matching id or other synchronization mechanism to pair the start and end elements.

- Forces to provide another mechanism to allow XML-friendly paired code for inline markup with no native data.


Cheers,
-yves