[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] XLIFF 2.0 and multiple <file> elements
Hi Bryan, Rodolfo, ----- "bryan s schnabel" <bryan.s.schnabel@tektronix.com> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]