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

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

Thanks Yves. I'm looking forward to your continuation. The fact that (1) is not possible is not obvious to me. I'm probably being tone-deaf. When you formulate the more later part, could you explain why (1) is not possible? If it is because in general we are moving away from 'x-', and adding it to <data> is therefore not possible, then we should fix the example in the xliff-core.pdf spec for 2.6.3.1.4:

<mrk id="m1" type="x-myCorp-isbn" value="978-0-14-44919-8">The Epic of Gilgamesh</mrk>

But I suspect that's not your reason.

Thanks,

Bryan

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Wednesday, October 03, 2012 10:37 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Best way to mark up an image in XLIFF 2.0?

I'll answer more completely later, but I just wanted to say that this:

(1) <data id="222" x-el_name="img" x-att_name="src">big-happy-smile.jpg</data>

Is obviously (at least from my viewpoint) not possible.
A solution with user-define element or attributes would use a namespace as you noted.

More later
-yves


-----Original Message-----
From: Schnabel, Bryan S [mailto:bryan.s.schnabel@tektronix.com] 
Sent: Wednesday, October 03, 2012 11:25 AM
To: Yves Savourel; xliff@lists.oasis-open.org
Subject: RE: [xliff] Best way to mark up an image in XLIFF 2.0?

Hi Yves,

I don't mean to be talking about two different things.

Sorry that I'm doing a poor job of communicating. 

True, my thinking about the fs attribute is lurking in the background. But I'm starting to think that (from my point of view) my fs answer  will not be impacted by this thread. I've not thought that  through yet.

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.

So for now, I'd rather not address ---1) in this thread.

And my answer to ---2) is that I actually don't want non-XLIFF XML in <data> at all. My preference would be to enhance the attribute set in <data>. Adding 'x-', or allowing the metadata namespace could help.

I just think something like this:

(1) <data id="222" x-el_name="img" x-att_name="src">big-happy-smile.jpg</data>

Or this:

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

Is better than this:

(3) <data id=”222”> &lt;img src="big-happy-smile.jpg /></data>

But since we have an improved skeleton now, and since escaping XML is doesn't seem to bother anybody but me, I will just  live with (3).

Thanks,

Bryan


-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Wednesday, October 03, 2012 8:18 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Best way to mark up an image in XLIFF 2.0?

Hi Bryan,

Again, I think you are talking about two different things:


--- 1) being able to use the fs attribute

You are using the content of <data> to generate your HTML preview (and find its plain-textness distasteful) because you have no other way to access the image URL. But this is because the core does not have any provision for this.

In short: it's a bit unfair to blame the core for not providing the information it's not suppose to provide.

Maybe the real problem is that fs should belong to its own module and provide additional features that make it work properly in an interoperable way.
For example: I doubt very much than the href value you will find in the original img tag will always be conveniently set to work out with your extracted files: The value may have a full or relative path that will not work with the files after extraction.

I think FS is not really useable as it is defined today. And the reason is because it tries to "fit" into the core. In my opinion it should be its own module and should have a standardized way to store the path of the images to display in the HTML preview. This would also allow tools generating FS markup to possibly convert images in not-easily displayable format used in various formats (InDesign, Word, etc.) into nicer .png/.jpg useable with HTML, and ship those with the XLIFF documents.

In short: the FS feature should be interoperable, not dig into the original data that may or actually may not be there.

For instance you could imagine something like this:

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

- XSL friendly
- not dependent on the original file format
- works even if the original data is omitted


--- 2) having escaped XML/HTML in the XLIFF <data> element.

As Rodolfo noted, it's an old well-known aspect of XLIFF.
Sure, we could allow for XML in <data>, but that comes with a whole set of new problems. Rodolfo mentioned some of them.

As you mentioned, having custom namespaces in the skeleton should allow you to build extraction/merge that are quite XML-friendly.

Cheers,
-yves



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




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