RE: [xliff] To extend or not to extend. Was: [xliff] Definition of "core" and "modules"

[Yves Savourel <ysavourel@enlaso.com>]

> I think we're all in agreement then. Your mention of using 
> <ph> is what I had in mind by saying that this made-
> up format would be treated just like IDML, Word, etc.

Actually I meant to say that *instead* of using the elements in your example, they could probably have a different set of elements/attributes that would work in the XLIFF core. So there would be no need for additional filtering, etc.

The following is such an example. Here it make probably no sense because I don't know what those elements means, but the idea is that you can likely adapt your data model to XLIFF.

<unit id="item1">
 <source><ph id='1' gx:ref='A'>$1</ph> kill<ph id='2' gx:ref='B'>{past}</ph> <ph id='3' gx:ref='C'>$2</ph> with a sword</source>
 ...
 <gx:varTextParams>
  <gx:textVariableSet var_id="A" number="sing" case="nominative">
   <gx:selector selectorID="1" gender="masc"><gx:name/></gx:selector>
   <gx:selector selectorID="2" gender="fem"><gx:name/></gx:selector>
  </gx:textVariableSet>
  ...etc.
 </gx:varTextParams>
</unit>

And that would be better than go to some proprietary format first, and then go to XLIFF from that proprietary format. The fewer intermediary steps the better.

By the way we do have a feature in the "proposed" category that deals with representation of plural. That may be related to your example. (http://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/Plural%20Entries)

Cheers,
-ys