RE: [xliff] Request approval of "Preserve XML attribute or metadata with

Hi Rodolfo,

That does help. As I was proposing it, I did not see the metadata holder as a sub-flow element, nor did I see it as inline markup. But that is just my blind spot I suppose (maybe more the former, and less the latter).

So that part of my proposal is drudging up old mud. I should remove that 10% but still think about the better method you adapted.

I'll answer that on the appropriate thread (that I just saw enter my mail box).

Thanks,

Bryan

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya
Sent: Tuesday, March 13, 2012 1:24 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal

Hi Bryan,

Your examples are based on the “old” XLIFF 1.2 and we are working on version 2.0. One of the details we all agreed for XLIFF 2.0 is that we will no longer have sub-flow elements in inline markup. All text belonging to a sub-flow should be in its own <unit>.

Your example:

<para id="g_3423_spectrum" alt="It's orders of magnitude faster" rev="c">This

is orders of magnitude faster than swept analysis techniques.</para>

needs to be stored in two <unit> elements, like this:

<source> This is orders of magnitude faster than swept analysis techniques.</source>

</segment>

</unit>

<source>It's orders of magnitude faster </source>

</segment>

</unit>

If we use the module for metadata that I proposed previously, you could have your attributes stored in this way:

<source> This is orders of magnitude faster than swept analysis techniques.</source>

</segment>

<mtd:metaHolder type=”x-attributes”>

<mtd:meta key=”id”> g_3423_spectrum </mtd:meta>

</mtd:metaHolder>

</unit>

<source>It's orders of magnitude faster </source>

<mtd:metaHolder type=”x-attribute-subflow”>

<mtd:meta key=”att-name”>alt</mtd:meta>

<mtd:metaHolder>

</segment>

</unit>

In the example above I placed metadata at two different levels. In the first case I used <unit> level to indicate attributes of the source XML element. In the second case I placed the data at <segment> level and indicated from which attribute it comes.

Any tool except your extraction filter should be able to safely ignore that metadata. As it would be only interesting for your tool, I prefixed the value in the “type” attribute with “x-“, as we used to do in old versions to indicate custom values.

Hope this helps,

Rodolfo

--
Rodolfo M. Raya rmraya@maxprograms.com
Maxprograms http://www.maxprograms.com

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Schnabel, Bryan S
Sent: Tuesday, March 13, 2012 4:01 PM
To: David Walters
Cc: xliff@lists.oasis-open.org
Subject: RE: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal

Hi David,

This is not at all related to the preview function (I think). It's just about round-tripping XML and not needing extensibility.

(spoiler alert, I've seen notes from this thread, after this one, where my eyes have been opened to the fact that the requirement may realistically be morphing into a general metadata handling issue, not just XML attributes. But for the excellent issues you raise, here goes . . .)

Attribute values (and names) need to be preserved in XLIFF whether we translate them or not. And beyond that, I think in some cases knowing the type could be useful in the translation workflow. I understand your point that having multiple translatable string sets in a single trans-unit is a new way of thinking. And I understand how this could be viewed negatively.

But to look at the flipside, I can also see negative aspects to storing attributes in two different ways depending on whether or not the attribute needs to be translated. And I perceive a need to preserve attributes w/o extensibility.

Going back to my example:

<para id="g_3423_spectrum" alt="It's orders of magnitude faster" rev="c">This is orders of magnitude faster than swept analysis techniques.</para>

In order to preserve the id, alt, and rev, and translate the alt, I suppose, off the top of my head we would do something like:

(a)

<trans-unit restype="x-myxml-para"

id="para-73"

mynspace:id="g_3423"

mynspace:alt="It's orders of magnitude faster"

mynspace:alt_idref="a1"

mynspace:rev="c">

<source> This is orders of magnitude faster than swept analysis techniques.</source>

</trans-unit>

<trans-unit restype="x-myxml_attribute-alt"

id="a1">

<source> It's orders of magnitude faster </source>

</trans-unit>

(perhaps I overlooked a better way than the example above)

But to tell you the truth, the idea of needing a second pair of <source>/<target> is an inelegance I completely spaced on (oh, boy). So let's see if my proposal still works with that reality:

(b)

<trans-unit restype="x-myxml-para"

id="para-73">

<source>It's orders of magnitude faster</source>

</meta-hold>

<source>This is orders of magnitude faster than swept analysis techniques.</source>

</trans-unit>

To my eyes, (b) looks a lot better than (a).

But I'm happy to hear why (a) is better than (b), or a better alternative is available.

Thanks,

Bryan

From: David Walters [mailto:waltersd@us.ibm.com]
Sent: Tuesday, March 13, 2012 7:42 AM
To: Schnabel, Bryan S
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal

What is the purpose of making these attribute values available within XLIFF? Is it related to the "preview" function that has been proposed? Providing this as a way to handle translatable attribute values does not seem to fit into the XLIFF structure very well. You would have to provide this text within <source> and <target> elements to make this translatable. Now you could have multiple (2+) translatable strings defined within one <trans-unit>. I thought we were tending towards making each translatable attribute value a separate <trans-unit> element.

I agree with Yves when he asked about why limit it to XML. This concept could apply to many non-XML file format, like HTML, resource files, message files, etc.

David

Corporate Globalization Tool Development
EMail: waltersd@us.ibm.com
Phone: (507) 253-7278, T/L:553-7278, Fax: (507) 253-1721

CHKPII: http://w3-03.ibm.com/globalization/page/2011
TM file formats: http://w3-03.ibm.com/globalization/page/2083
TM markups: http://w3-03.ibm.com/globalization/page/2071

"Schnabel, Bryan S" ---03/12/2012 06:23:37 PM---I move that we promote the proposed feature, "2.21. (B25) Preserve XML attribute or metadata without

From: "Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>
To: "xliff@lists.oasis-open.org" <xliff@lists.oasis-open.org>
Date: 03/12/2012 06:23 PM
Subject: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal
Sent by: <xliff@lists.oasis-open.org>

I move that we promote the proposed feature, "2.21. (B25) Preserve XML attribute or metadata without extensibility" (http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-PreserveXMLattributeormetadatawithoutextensibility.A.28B25.29PreserveXMLattributeormetadatawithoutextensibility ) to section 1, as an approved feature for XLIFF 2.0 (http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#ApprovedFeaturesforXLIFF2.0 ).

If any voting member of the TC agrees, please second.

Here's some background.

Today we nearly always need to use extensibility to preserve source XML attributes when converting an XML file to XLIFF. We should create a way to preserve the attributes using supported XLIFF markup - removing the need to extend.

Consider this XML element:

<para id="g_3423_spectrum" alt="It's orders of magnitude faster" rev="c">This is orders of magnitude faster than swept analysis techniques.</para>

If we were to allow an element like <meta-hold> (would really need to come up with a better name though) to contain the name of the attribute, its value, and optionally its type and translate y/n, we would eliminate the need for extensibility for this use case.

Example:

<trans-unit id="para-73">
<meta-hold name="id" translate="no">g_3423_spectrum</meta-hold>
<meta-hold name="alt" translate="yes">It's orders of magnitude faster</meta-hold>
<meta-hold name="rev">c</meta-hold>
<source>This is orders of magnitude faster than swept analysis techniques.</source>
</trans-unit>

I include the following, not to propose to specifically update the schema in this manner, but rather to provide more background on the proposed data types and constraints.

Modification to schema:

<xsd:element name="meta-hold">
<xsd:complexType mixed="true">
<xsd:group maxOccurs="unbounded" minOccurs="0" ref="xlf:ElemGroup_TextContent"/>
<xsd:attribute name="name" type="xsd:string" use="required"/>
<xsd:attribute name="type" use="optional"/>
<xsd:attribute name="translate" use="optional"/>
</xsd:complexType>
</xsd:element>

Allow the usual inline elements, but do not allow nested <meta-hold> elements

<xsd:group name="ElemGroup_TextContent">
<xsd:choice>
<xsd:element ref="xlf:g"/>
<xsd:element ref="xlf:bpt"/>
<xsd:element ref="xlf:ept"/>
<xsd:element ref="xlf:ph"/>
<xsd:element ref="xlf:it"/>
<xsd:element ref="xlf:mrk"/>
<xsd:element ref="xlf:x"/>
<xsd:element ref="xlf:bx"/>
<xsd:element ref="xlf:ex"/>
</xsd:choice>
</xsd:group>

Please feel free to join this discussion if you have questions, concerns, objects, or if you support this idea.

Thanks,
Bryan Schnabel
Content Management Architect
Phone: 503.627.5282
www.tektronix.com

xliff message