RE: [xliff-inline] Storing native data

["Lieske, Christian" <christian.lieske@sap.com>]

Hi Yves/all,

Please find a couple of thoughts/comments below. They refer to some of the concepts/terminology suggested in http://lists.oasis-open.org/archives/xliff-inline/201012/msg00002.html ...

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

I would tend to rephrase this as follows:

In cases where supplementary entities related to inline entities, or surrogate entities (for "illegal/non-XML" characters) have to be represented, two representation mechanisms can be envisioned:

1. attached to the material to which it pertains (corresponds to b) )
2. detached from the material to which it pertains (corresponds to c) )

I wonder if we really should come up with suggestions for both mechanisms. Is there a requirement to have both? If not, I would tend to think that we should only devise a single representation. This presumably will be beneficial for interchange (since tool's providers only have one choice how to represent/implement the aforementioned entities).

As for ideas related to the possible representation mechanism, two things come to mind:

1. distinguishing between "carrier" and "data"
2. using XPointer

The distinction between "carrier" and "data" pertains to the following observation: The "data" in the example could be stored outside of the "carrier" (here: the "start/end" attributes).

	Example:

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

	Alternative:

		<pc id='1' start='d1' end='d2'>text</pc>

		<data id="d1">[data]</data>
		<data id="d2">[/data]</data>

We thus introduce a level of indirection - and need a mechanism to establish a link between the "carrier" and the "data". This could be done via XPointer in various ways.

One possibility is to use XPointer in the "carrier":

		<pc id='1' start='xpointer(id("d1"))' end='xpointer(id("d2"))'>text</pc>

		<data id="d1">[data]</data>
		<data id="d2">[/data]</data>

Another possibility would be to use XPointer in the container for the "data":

		<pc id='1' start='d1' end='d2'>text</pc>

		<data attachmentPoint='xpointer(id("d1"))'>[data]</data>
		<data attachmentPoint='xpointer(id("d2"))' >[/data]</data>

If I understood XPointer correctly, you may even get rid of the "carrier" since XPointer does not only allow you to easily identify even strings. Example:

		<pc id='1'>a text of high importance</pc>

		<data attachmentPoint='xpointer(string-range(/,"high"))'>[data]</data>

This would attach "[data]" to any string "high".

Best regards,
Christian

-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com] 
Sent: Mittwoch, 1. Dezember 2010 22:59
To: xliff-inline@lists.oasis-open.org
Subject: [xliff-inline] Storing native data

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



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