OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-inline message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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] | [List Home]