OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal



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:




   <source>Translate me!</source>

  <mtd:metaHolder type=”attributes”>

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

    <mtd:meta key=”bold”>yes</meta>


  <mtd:metaHolder type=”count”>

    <mtd:meta key=”words”>2</meta>

    <mtd:meta key=”chars”>13</meta>




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.




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 Yves Savourel
Sent: Tuesday, March 13, 2012 11:17 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal


Hi Bryan,


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?







From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Schnabel, Bryan S
Sent: Monday, March 12, 2012 5:23 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal


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.




<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>



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"/>




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


    <xsd:group name="ElemGroup_TextContent">


            <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"/>




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



Bryan Schnabel
Content Management Architect
Phone: 503.627.5282

TwitterRSS Facebook Tektronix Store

Tektronix Logo


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]