RE: [xliff] Preserve XML attribute or metadata without extensibility

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

Hi Yves,

(my favorite part of your note, obviously, is the colorful and creative statement on 'ugly')

Thanks to the follow-up from you and Rodolfo on this thread, a more complete view of a sensible requirement is beginning to take the place of the vague starting point I struck. I think the "name" of the *problem* we are trying to solve is still okay "preserve XML attribute or metadata without extensibility." Here's something of a summary of the points that make up the maturing problem statement and some pitfalls in 1.2.

Fact: we absolutely can preserve any XML source attribute, today, in XLIFF 1.2, an be in full compliance with the spec and schema, but most of the solutions are 'ugly' (for a definition of ugly, see Yves' note below).

1) - It is perfectly legal and easy to add extension point to <group>, <trans-unit>, <source>, and <target>. Attributes and their values may be stored there. Problem: this leads to processing limitations between tools (etc.).

2) - It is perfectly legal to store *code* in the skeleton. Attributes of wrapper elements and their values may be stored there. Problems: No solution for inline elements. Cannot store native XML in skeleton (internally). If you want to store XML it will require extension plus you must actually locate the XML outside of the <skl> element. Ironically neither <skl>, <internal-file>, nor <external-file> have allow extension points. This fits our criteria for both incompatibility and ugliness.

3) - " Maybe there is a need to have something at the <unit> level that is the same as <ignorable> in the segment. In other words: an official way to have XLIFF used as a layer on top of the original file" Problem: hmmmm?

- Bryan

-----Original Message-----
From: Yves Savourel [mailto:ysavourel@enlaso.com] 
Sent: Tuesday, August 30, 2011 12:28 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Preserve XML attribute or metadata without extensibility

Hi all,

Bryan, I think the root of the problem you are having with XML + XLST -> XLIFF is about storing your skeleton. Even in 1.2: Technically nothing would prevent you to put the whole original XML in the skeleton, and re-process it, replacing only the text where needed.

The approach of taking the original file and putting an XLIFF structure on top of it is not very well handled today because 1.2 has no facilities to store skeleton between <trans-unit>.

But even with 1.2 you can work around this by using inline codes:

<source><ph id='1'>&lt;para id="g_3423_spectrum" alt="</ph>It's orders of magnitude faster<ph id='2'>" rev="c"></ph>This is orders of magnitude faster than swept analysis techniques.<ph id='3'>&lt;/para></ph></source>

It's more ugly then the rotten teeth of a naked mole rat without dental insurance, but it works. At the same time inline codes are not meant to store external skeleton: it adds codes in the XLIFF content. In 2.0 something with <ignorable> would be nicer, as Rodolfo pointed out.

But ultimately those structural codes should probably be out of the trans-unit altogether. Maybe there is a need to have something at the <unit> level that is the same as <ignorable> in the segment. In other words: an official way to have XLIFF used as a layer on top of the original file.

Just thinking out loud...
-ys


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php