RE: [xliff] Best way to mark up an image in XLIFF 2.0?

[Yves Savourel <ysavourel@enlaso.com>]

Hi Bryan,

Ok here is the "more later" part now:

> In this thread I just meant to talk about 1 thing. 
> I was just seeking to learn the recommended way to mark up 
> an image, and expressing my discomfort that the 
> answer is to escape XML, in order to represent XML, 
> in an XML interchange format.

Let's focus on that first then.

"How images are represented in XLIFF 2.0?"

The answer is: the *original code* of an image as described in you example would be stored in a <data> element, more or less like the following:

<unit id="1">
 <segment>
  <source>This is a test <ph id="1" nid="d1"/> to see how to embed images.</source>
 </segment>
 <originalData>
  <data id="d1">>&lt;img src=big-happy-smile"/></data>
 </originalData>
</unit>

This is not satisfactory to you because the original data is not in XML.

So I'm asking: What exactly do you need to access the original code in the first place?

I know the answer to that from the initial email of the thread: it basically says you want to access the src attribute of an <img> element, in order to use it to illustrate how fs can work perfectly well.

So the real question is "How do you get the URL of the image that represents an inline code of type image in XLIFF?"

That a very different things.

You are assuming a) that how the original markup is stored for the image is relevant to access its URL.
And b) that you'll be using the same image in the preview.

Storing the original markup of an image object and accessing the file that represent that image for the HTML output are completely separate issues. We have a way to do the first, not yet a way to do the second.

Accessing the file that represent the image needs to be interoperable: Any tool that implement FS should be able to access the image representation if one is available, not just the one understanding the original format.
Otherwise FS is just a custom mechanism and should not be in our specification.
We should be able to use that mechanism for a .png file in a web site as well as an embedded graphic in a InDesign file.
This also means the image to preview may not be the actual original image in its original format.

Such common access cannot be done in the original data (regardless if it is represented in XML or not). The extractor tool needs to abstract that information and store it in a standardized way.
 
The <data> element has only the requirement to allow the merging back of the data. We should not burden the core with extra requirements such as "When the original format is HTML, the URL of the <img> element should be accessible."

Hence my thoughts that the FS mechanism could/should be more powerful and have its own module. One of its features would be to provide a way to store a URL to an image representing the original image in the original document.


As for <data> and images. We certainly could come up with various ways to decompose the original code of the image store that information using attributes, etc. like in your example:

<data id="222" codeName="img" codeMeta="src">big-happy-smile.jpg</data>

But: I don't think we could support all formats that way. How would we store embedded IDML images, or Franmeaker insets, or ODF pictures? But more importantly: why the complication? Do you have a use case where accessing the various parts of the original image code is required? I don't think FS is such use case.

I hope this helps explaining my view point.

Cheers,
-yves