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] [reintroducing proposal] Propose promoting "(B25) Preserve metadata without using extensibility" to section 1 (approved)


 

I second Bryan’s proposal.

 

Regards,

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 7:41 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] [reintroducing proposal] Propose promoting "(B25) Preserve metadata without using extensibility" to section 1 (approved)

 

Hello,

 

Sorry for the extra emails.

 

I propose we  promote "(B25) Preserve metadata without using extensibility" (http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-PreserveXMLattributeormetadatawithoutextensibility.A.28B25.29Preservemetadatawithoutusingextensibility ) to section 1 (approved).

 

If any TC voting member agrees, please second.

 

In XLIFF 1.2 we sometimes need to use extensibility to preserve source metadata when converting an source files to XLIFF. For XLIFF 2.0, there is a need for preserving metadata; the solution should be generic and contemplate formats like HTML5, PO, or XML attributes in general - removing the need to extend.

 

Consider this source:

 

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

 

We could introduce a module that could store the metadata, with hints that an application could optionally use, for purposes of roundtripping, applying/reporting metrics, etc.

 

For example:

 

<unit id=”a1”>

  <segment>

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

  </segment>

  <metaHolder type=”attributes”>

    <meta key=”rev”>c</meta>

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

    <meta key=”alt” id="a1.a">It's orders of magnitude faster</meta>

  </metaHolder>

  <metaHolder type=”count”>

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

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

  </metaHolder>

</unit>

<unit id=”a2” idref="a1.a">

  <segment>

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

  </segment>

</unit>

 

 

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.

 

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

TwitterRSS Facebook Tektronix Store

Tektronix Logo

 



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