Re: OASIS OpenDocument Essentials

[email protected] Tue, 5 Jul 2005 09:33:39 +0900
Newsgroups gmane.comp.openoffice.devel.xml
Message-ID <[email protected]>
> So let me rephrase my statement: it's impossible to calculate the
> visibility of an *arbitrary* XML element in the file without rendering
> the complete document. If you exclude the latter from the possible
> options I think it's even theoretically impossible. :-)

Ok, I think I understand what you mean :)

I my original question sounded a little abstract, let me explain where 
I come from, just to make it sound like I was not totally nuts in the 
first place :)

One single file embedded as a number of objects in a master file will 
generate the same number of object files with different parts 
displayed. The only difference between the objects is thus the 
settings.xml file.

Problem was/is/ and look like it will be, that translating the master 
file in a sx./od. supporting tool means that the tool will have to 
access multiple instances of the same file without knowing that they 
are the same, and even if there was a way for it to know, there is no 
way for it to actully restrict itself to the actually visible data on 
the master file.

Besides, in the case of multiple instances of the same content.xml file 
to describe OLE objects from the same original file, there seem to be 
no way to indicate which object is on which part of the master file. 
Which makes visual checking an impossibility in the case of complex 
master files embedding complex objects.

I am discussing the possibility to have OLE objects supported in a 
variety of translation memory tools (including the ex-Sun Translation 
Editor, now Open Language Tools) and I see that we have a major problem 
here :)

I don't know how MS and related translation tools (like Trados) fare in 
this field so I can't really compare, and I truly understand the 
limitation you describe.

But I am thinking that, considering OD. is going to be a EU standard, 
and seeing how much of EU work is based on translation (ok, mostly 
legislative work, but also a lot of economy related complex documents 
including embedded spreadsheets, charts graphs etc) I think OD. is 
going to need a few more visible data access function for the 
translation process.

Sincere regards,
Jean-Christophe