OASIS Open Mailing List Archives  ·  All Lists  ·  xliff-inline  ·  2011-07

xliff-inline — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

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


Hi, Looking back at one of Christian comments on the inline 'native' data representation. I wonder if this (or something derived from it) could not be an alternative for the representation of "ignorable" > 2. Looking at the similarities between the storage location > and the skeleton, three ideas come to mind: > a. call the storage location "local-skeleton" > b. define it not in the same way as "skeleton" (most > importantly, allow XML to be included) > c. work along the lines of some existing skeletons > (special markers, in locations with translatable text) > ... > <local-skeleton> > <x id="1"/> <span style="background-color: #FFFF00"><x id="2"/> > <b><x id="3"/> </b> <x id="4"/> <i><x id="5"/> </i> <x id="6"/> > <b><x id="7"/> <i><x id="8"/> </i></b> <x id="9"/> </span><x id="10"/> > </local-skeleton> One could imagine storing all the ignorables in a single element and using placeholders for the segment references. A sort of unit-level skeleton. <unit id='1'> <ignorable> <src><s id='1'/> <s id='2'/></src> </ignorable> <segment id='1'> <source>Text 1.</source> </segment> <segment id='2'> <source>Text 2.</source> </segment> </unit> Just a thought. I'm not sure if it's more advantageous than using the current proposed representation. But I guess that's a topic of the main TC list at some point. -ys

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]