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


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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

Subject: FW: Interesting XLIFF Application


Tony and Yves suggested I should share this with other who might find this
interesting.  It's in the very early stages, but could be an interesting

In short, I've roughed out an application that takes any well-formed XML,
transforms it into a "generic" XLIFF file, and then transforms it back to
its original doctype (presumably after the XLIFF file has been translated).

It's got many rough spots, but it should convey the concept.

Please feel free to run your own XML file through, and see what happens.



-----Original Message-----
From: Schnabel, Bryan S 
Sent: Wednesday, March 10, 2004 3:39 PM
To: 'tony.jewtushenko@oracle.com'
Cc: 'ysavourel@translate.com'
Subject: Interesting XLIFF Application

Hi Tony,

You might find this interesting.  I was pondering the difference between the
science of writing XLIFF filters vs. the art of writing XLIFF filters.

I concluded that one could actually create a reliable algorithm and write a
generic application that would take any XML instance, transform it to XLIFF,
and then transform the XLIFF back to the original doctype.

So that's what I did.  If you're interested, and have a few minutes, feel
free to take a look at the attached group of files.  

Please feel free to test this with any of your own xml files.  A caveat,
this is currently in early development stages.  I expect to have to fix it
once it undergoes tests.  This is just meant, for now, to demonstrate my
strange idea.  But it's worked on the variety of samples I tried so far.

I'd like to get your opinion.  If it's just a bad idea, please feel free to
say so.  If it could be polished, developed, and useful going forward (maybe
the subject of an article, i.e., the kind you've encouraged me to write in
the past), I'll be happy to take it a bit further.  Or if it's just good for
a chuckle, that's fine too; we could all use a good laugh I suppose.

I included the following:

-- toGenXLIFF.xsl
This is an xslt that transforms any* well-formed instance into XLIFF (the
XLIFF is valid, but some of the mapping I chose might need to be improved. .

-- fromGenXLIFF.xsl
This is an xslt that transforms the XLIFF back to its original doctype (the
idea would be to have the target strings translated first).

-- pid.xml
-- ru-qsum.xml
These are a couple sample input xml files I grabbed (and to some degree,
hacked together for testing), that represent different doctypes and source

-- gen-pid.xlf
-- gen-ru-qsum.xlf
These are the same files, after I transformed them to XLIFF, with

-- back-pid.xml
-- back-ru-qsum.xml
These are the same files, transformed back to their original doctype, with

-- GenXLIFF.bat  
This is a simple bat file that performs the round trip via the saxon xslt
processor (any xslt processor will do).

I copied Yves because I our work on the HTML project got me thinking about
strategies for mapping elements depending on their content (mixed vs.
#PCDATA vs. wrapper vs. EMPTY, etc.).  If you feel other people from the TC
would be interested, feel free to share this with whoever you like.




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