Re: [xliff] RE: [xliff-inline] Propose 2 enhancements to @fs

["Dr. David Filip" <David.Filip@ul.ie>]

Hi Bryan, all,

let me explain how I understand the purpose of fs.

It is a necessary and minimal context preview mechanism and as such it belongs to the core IMHO. Context is all important for translation and we should not send the bad message to the community by not having a preview mechanism in the core.

I am not at all worried that it cannot address showing images in rtf or dtp formats. we should not be mixing the source and the preview format, as they are different things and have different purposes. fs is a minimum preview mechanism that is accessible to everyone up and down the lane. It is the extractor's worry if they are able to use simple html preview provisions for representing a simplified version of their context, and it is not in fs scope to solve this. Some may decide that representing rtf via fs is a worthy cause and they may join forces and spec a best practice committee note for that end. But such a note is by no means a part of the core fs functionality. Providing fs preview artefacts is IMHO not necessarily connected to the real skeleton that is needed for merging back. In fact in most cases (even most HTML cases) the fs will be much simpler than the real thing.. This said there should be a best practice mapping for a small number of formats..

Nevertheless, I do agree with Yves that the fs should be designed with HTML (or XHTML) well formedness in mind and I also think that a minimal viable xsl leading to a valid html display is in scope of the feature.

The discussion so far opened lot of interesting issues around skeleton, local and internal and so on, but I think that fs as it was scoped on the feature tracking wiki is only very loosely related to the discussions. I'd very much like to see fs as simple html preview mechanism (no matter what the source) and part of core.

The conformance should be like this. If a tool provides a simple html preview via xliff, it must do so using fs. This does not prevent people from using proprietary, heavy duty, and high fidelity mechanisms linked to the real skeleton..

Thanks and cheers

dF

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

mailto: david.filip@ul.ie

On Mon, Oct 8, 2012 at 3:36 PM, Schnabel, Bryan S <bryan.s.schnabel@tektronix.com> wrote:

Hi Yves,

I agree with you and Rodolfo that the I way used <data> to illustrate a way to include images in an HTML representation was under specified. I should have made it clear I was showing "a" way, not "the" way.

I think what it comes down to in my mind is that the fs has a very narrow jursidiction, and for my part I've been more focussed on limiting it to be used within it's scope - rather than expanding so that it might be used for things that it is not meant to do.

Bottom line, I think fs can be used on *some* XLIFF files in *some* situations - but not all XLIFF files for all situations. Our trickiest example so far is images. For this example I would say if the XLIFF file has a clear way of marking up the images, and if rendering images is important for the in context review, then the fs writer (using whatever language to decode and render) has a reasonable hope to present them in a just-in-time browser rendering. Who knows, reasonable markup could exist in the <data> element, or in the skeleton, or in an external file. But in some cases, where the XLIFF file does not manage the clues about the images, or does so in a way that is beyond the fs levers, then images are simply off the menu. For example, if embedded bitmaps are stored for XLIFF RTF, or desktop publishing files, and if the fs decoder doesn't have the horsepower to render these, I guess that's a use case where fs is not a good fit (or maybe it is, if the fs decoder has the chops).

As for the other tricky situations you mentioned, yes, they would need to be dealt with. Multiple <file> elements is something I deal with all the time. But I don't think going down that lane is useful for me to do at this point.

I did not envision specifying fs in such a way that it could anticipate every corner case. I just thought it would be good for most, or even some cases.

But that's just my vision. If other members of the TC have more ambitious ideas, I welcome them.

Thanks,

Bryan

ps., This exercise was good for one thing. It inspired me to write a PERL script to roundtrip XLIFF-RTF. It might be ready for others to look at soon.

________________________________________
From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Yves Savourel [ysavourel@enlaso.com]
Sent: Saturday, October 06, 2012 8:04 AM
To: xliff@lists.oasis-open.org
Subject: [xliff] RE: [xliff-inline] Propose 2 enhancements to @fs

Hi Bryan,

I agree with Rodolfo: one shouldn't rely on the content of <data> for generating an HTML representation.

For example, you are saying that for RTF you don't need a lot to adjust your XSLT template to generate the same output. That's not true if the image to represent is embedded (instead of referenced like in your example).

The tool generating the HTML view should be agnostic of the original format.
That is the whole point of XLIFF: work at an abstracted level, so the data can be treated the same way by all the tools.

This is why I was pointing out in my earlier email (https://lists.oasis-open.org/archives/xliff/201210/msg00042.html) that if you want to represent an image in the HTML preview, the FS mechanism needs to provide a way for the extraction tool to store an interoperable information about the image to display.

I think to really work, fs cannot be just an attribute allowing a bunch of HTML tag names. It needs to be its own module, with clear processing expectations associated with the core elements, and provides support data when needed (like the image information).

Other examples of issues with the current mechanism:

- Stick two <file> elements like your example instead of one in your <xliff> document and your XSLT template will generate an output with two <body> elements.

- What if a tool decides to put an fs='html' somewhere, how would the template know what encoding to associate with it, etc.

I'm guessing your answer would be that the template is meant to work with a specific type of XLIFF document, not all of them. Then, to me, it means it's not relying only on fs and therefore fs (as it stands now) is not interoperable and thus shouldn't be part of the core or even an official module.

In my opinion there is nothing wrong with the goal of fs, but the mechanism needs to be interoperable. The same XSLT or Java code should be able to use the fs mechanism of any document and generate a meaningful output from it.

My initial remarks on fs that prompted you to develop this example were because I was trying to use fs in an example tool of the toolkit. And quickly it became clear that there was too many assumptions the tool had to make to be able to do something useful.

Cheers,
-yves



---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org




---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org