Next in thread → Next in month →

Storing native data

From
Christian Lieske
Date
2010-12-06T08:56:00+00:00
ID
Thread
Storing native data
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:



	Alternative:



		<data>[data]</data>
		<data>[/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":



		<data>[data]</data>
		<data>[/data]</data>

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



		<data>[data]</data>
		<data>[/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:



		<data>[data]</data>

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

Best regards,
Christian
Next in thread → Next in month →