[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] RE: [xliff-inline] Propose 2 enhancements to @fs
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]