Re: [xliff] XLIFF 2.0 and multiple <file> elements

Hi Bryan, Rodolfo,

----- "bryan s schnabel" <> wrote:
> I agree with Rodolfo that multiple <file> elements are important (or
> to put it more strongly, "critical"). Rodolfo's 1) thru 4) use cases
> list looks bullet-proof to me.

Thank you both for your comments on my question. I do agree with what you say - multiple <file>s within a single XLIFF container is a critical feature. 

> Of your two proposals, the first, for me, weakens XLIFF's utility. But
> the second one seems like it could add value:
> 
> > <xliff>
> >   <header>
> >      // workflow data
> >      // tool information
> >      // other meta-data relating to the whole container
> >   </header>
> >   <files>
> >     <file original='myfile.txt'>..</file>
> >   </files>
> > </xliff>
> 
> With my XML Information Architect hat on, I would suggest that the
> proposed <header> element could be useful, but I'd pick a better name
> (since <header> is already a (useful) child of <file>, and <header> as
> a child of <xliff>, would be used for a different purpose).

Yes, I agree. Perhaps the wrapper element is not needed here at all, as in the following example:

<xliff>
  <tool id="mytool" version="1.0" mytool:checksum="a1db2bfc34b2" />
  <tool id="othertool" version="1.0"/>
  <phase id="content-extraction" tool-id='mytool' />
  <phase id="pre-processing" tool-id='othertool' />
  // xs:any extension point
  <file .. />
  <file .. />
  <file .. />
</xliff>

> And the <files> wrapper element might be redundant if its utility
> could be covered in the proposed <header> element.

Yes, I haven't found any Oasis guidelines on the use of wrapper elements. In some cases they make the format more intuitive to read, and certainly a bit easier to process outside of xpath-based tools. However, it is certainly more verbose if you take it to its extreme:

<xliff>
 <tools>
  <tool id="mytool" version="1.0" mytool:checksum="a1db2bfc34b2" />
  <tool id="othertool" version="1.0"/>
 <tools>
 <phases>
  <phase id="content-extraction" tool-id='mytool' />
  <phase id="pre-processing" tool-id='othertool' />
 </phases>
  // xs:any extension point
 <files>
  <file .. />
  <file .. />
  <file .. />
 </files>
</xliff>

One implication of this proposal is that by putting some meta-data on the xliff level rather than the file level, we no longer allow processing a single <file> in the same way as before, as there is some 'shared' meta-data that can be modified outside the scope of the <file>. 

cheers,
asgeir