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

[Yves Savourel <ysavourel@enlaso.com>]

Hi Bryan, all,

> 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.

To me it's not a matter of scope (how much the fs mechanism should allow the renderers to do), it's a matter of interoperability (all tools should be able to use fs when present). Having a "reasonable hope" to be able to access the proper data is not going to work.

A mechanism that is defined in the XLIFF specification (core or module) should not rely on <data> or the skeleton to do something, because the specification only define a place where to put the original data.


> 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.

Again, this is my point: if you want the fs mechanism to display images in an interoperable way, it's easy: add to the fs mechanism a way to store the path to the image to render. Then tool generating the fs markup can also provide the images (if it's doable), and the mechanism stays interoperable.

Cheers,
-yves