From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Schnabel, Bryan S
Sent: Tuesday, March 13, 2012 4:15 PM
To: Rodolfo M. Raya; firstname.lastname@example.org
Subject: [xliff] General metadata preservation, not just XML attributes (was RE: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal)
I love this proposal. This covers 90% of my intent - plus 100% of Yves' concern. I wonder if we could add the remaining 10% of my intent by adding a translate y/n dimension? But in doing so, it would be important to keep in mind David W.'s excellent point that adding a second <s>/<t> pair would be a game-changer (http://lists.oasis-open.org/archives/xliff/201203/msg00028.html ).
I am very much leaning toward doing the following.
1. withdraw my earlier proposal (and with that David's second goes away)
2. ask that you co-own this feature
3. add your generi-sized and improved functionality to the wiki summary
4. decide if translatable strings are in scope
5. re-propose the feature after dispensing with 1 thru 4
What do people think of this approach?
There shouldn’t be something specific for XML. If there is a needs preserving metadata, the solution should be generic and contemplate formats like HTML5 or PO as well.
We could recover the concept of “group” from XLIFF 1.2 and implement it as an optional module that would allow storing information at different levels, like <file>, <unit>, <segment> and <match>.
With two elements living in a separate namespace we could store lots of optional information like in this example:
One attribute in the main holder element would indicate the type of metadata and another attribute would define the key of a key-value pair.
In the module specification we could define a set of standard information types that covers what we have in XLIFF 1.2 and add new ones as needed to cover things that are currently handled by custom extensions in XLIFF 1.2.
This schema used in <match > or <matches> would be quite useful for storing metadata that today we can’t store in <alt-trans>.
Applications that don’t understand certain type of metadata would be able to safely ignore the proposed elements, as with any element coming from an optional module.
Could you define what “metadata” means in your example? Is that implying that some of the metadata could be XML element content too?
I’m also wondering why XML source documents should have a specific way of being stored? Couldn’t HTML5 metadata be also important for example?
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.
<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>
<source>This is orders of magnitude faster than swept analysis techniques.</source>
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: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"/>
Allow the usual inline elements, but do not allow nested <meta-hold> elements
Please feel free to join this discussion if you have questions, concerns, objects, or if you support this idea.
Content Management Architect