RE: [xliff-inline] Storing native data

[Yves Savourel <ysavourel@translate.com>]

Hi Christian, all,


> I wonder if we really should come up with suggestions 
> for both mechanisms. Is there a requirement to have both?

Yes there is.


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

From a practical viewpoint I'm not sure if we would want to "burden" an XLIFF document with XLink syntax for every single inline code.
It seem this would also restrict the way tool can work, forcing them to use XLink, and possibly preventing XLIFF implementation where XLink processor is not available.
But linking the data to the code using a unique id could certainly be used. And implemented in XLink for the applications choosing to do so.

This separation between the code tag and its corresponding data is used by SDLXLIFF currently. I wonder if anyone has any feedback on its usage: What are its advantages vs. its drawbacks? For example it seems relatively easy to work with when you have the whole document in memory, but it may be less practical when using a stream-based parser, or when working with snippet of XLIFF, etc.

-ys