[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]