RE: [xliff-inline] Native data - "outside" representation

[Yves Savourel <ysavourel@translate.com>]

Hi Christian,

>> Why? Wouldn't the skeleton file and the local storage
>> complement each other.
>> After all we don't disallow skeleton file if the 
>> inline codes store the native data inside the code.
CL> I would see a certain danger (e.g. related to consistent
CL> modification) if some native code is stored in both the 
CL> skeleton and the local-skeleton. I would also think that 
CL> interoperability suffers if some tools work with the 
CL> skeleton and others with the local-skeleton when it comes
CL> to native data.
CL> That's why I suggested to go for an exclusive OR when it 
CL> comes to skeleton vs. local-skeleton.

Maybe I mis-understood, but I thought the local-skeleton would be for the original data of inline codes only. Basically another way to store those data that can also be represented inside the inline elements.
For example: in "<p><b>text</b></p>"
"<p>" and "</p>" would be in the skeleton
"<b>" and "</b>" would be in the local-skeleton (or alternatively inside the inline elements)
Just like 1.2 offers today.

But I guess the ultimate goal I think you are aiming for is probably a standardized skeleton :)


CL> I understood your "XLIFF and native data" as follows:
CL> a. Sometimes, my XLIFF A at hand will not be derived from 
CL> a native format, but rather from XLIFF B; we could term 
CL> the XLIFF A "second order XLIFF".
CL> b. Talking about "native" in second order sounds kind of odd
CL> That's why I suggested to avoid the term "native" and just 
CL> talk about container/skeleton.

You understood what I meant.
I was confused by "skeleton" in that context as to me (so far) it referred only to the structural codes, the "external" stuff, not the codes inside the extracted content. But I see what you mean now.

-ys