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

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

Hi Yves,

Ok. Now I’ve got it. (1) Make fs interoperable; (2) Add an fs mechanism to store the path of images to render. And presumable doing (2) helps achieve (1).

Maybe we are in violent agreement after all.

I’m in favor of (1) – and I’m not aware of how anything I said earlier in the thread is counter to that, including my observation that some XLIFF will be good candidates for fs, and some XLIFF will not (interoperable - ly, across the board for all). Example, I cannot imagine my firmware XLIFF files lending themselves to a just-in-time browser view facilitated by fs – nothing to do with interoperability.

If you are saying that my attempts to render images via fs, based on non-fs-contained information, located elsewhere in an XLIFF file contradicts interoperability – I say okay – let’s fix it (which leads us to (2)).

Regarding (2) – were you just talking about images? Or do we want to  add a mechanism to fs to address other potentially tricky browser rendering situations as well (like maybe cross references, variables, entities, conrefs, OOP . . .)?

My reason for asking, if it’s just image paths, I agree with you that the solution is easy. I have no qualms about, for example, breaking fs into a pair of attributes. We could have fs-element and (optionally) fs-path:

 <segment>
              <source>Science is <ph id="1" /> good.</source>
              <target fs="p">&#31185;&#23398;&#36824;&#26159;&#19981;&#38169; <ph id="1"  fs-element="img" fs-path=” big-happy-smile.jpg” /> &#30340;&#12290;</target>
 </segment>

The only tricky thing I can think of in this case is how to express in XML Schema that @fs-path can only exist if @fs-element exits.

I just wonder how far down the rabbit hole we’d have to go if we tried to solve fs issues for every situation (beyond just images) we could think of.

Eager for more thinking on this topic,

Bryan

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Monday, October 08, 2012 9:30 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] RE: [xliff-inline] Propose 2 enhancements to @fs

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



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