RE: [xliff] Metadata extensibility with metaHolder

[Yves Savourel <ysavourel@enlaso.com>]

Hi Kevin,

I think, if we go with metaHolder, the proposal improves it.
A few notes:

> The main advantages that we see are:
> • Readability ...

It seems to me that, as far as machine readability goes, having key/values pair as attribute+value or element+content is simpler, leaner and can be validated more easily then <meta>. Same for human readability.


> • Avoids disturbance of the translation unit,
> and the possibility of limiting recycling leverage

I'm probably missing something, but I'm not seeing how the metaHolder is any different to a custom namespace for those two things. 

For instance, here is your example along with its equivalent in an imaginary namespace:

<unit id='1'>
 <source>
  <segment>Some text</segment>
  <metaHolder>
   <meta type="file" key="reviewComments" path="data/comments" provider="MicrosoftLocABC">comments.csv</meta>
   <meta type="regex" key="rule001" provider="MicrosoftLocABC">m/(\d+)/)</meta>
   <meta type="xs:string" key="foo" provider="MicrosoftLocABC">bar</meta>
   <meta type="xs:integer" key="age" provider="MicrosoftLocABC">35</meta>
   <meta type="Microsoft-WinLoc:locData" key="locBusinessData" provider="MicrosoftLocABC">en-GB;string;Hello;1437</meta>
  </metaHolder>
 </source>
</unit>

<unit id='1'>
 <source>
  <segment>Some text</segment>
  <ms:winLocMetadata>
   <ms:reviewComments path="data/comments" provider="MicrosoftLocABC">comments.csv</ms:reviewComments>
   <ms:regex key="rule001" provider="MicrosoftLocABC">m/(\d+)/)</ms:regex>
   <ms:foo provider="MicrosoftLocABC">bar</ms:foo>
   <ms:age provider="MicrosoftLocABC">35</ms:age>
   <ms:locBusinessData type="Microsoft-WinLoc:locData" provider="MicrosoftLocABC">en-GB;string;Hello;1437</ms:locBusinessData>
  </ms:winLocMetadata>
 </source>
</unit>

I can't see any problem the namespace version creates that does not exist for the metaHolder as well.

There is one advantage for metaholder. It's what you called "predictability". That is without question a plus on the metaHolder column (the only one in my opinion): All tools can use that same pre-defined structure and whatever set of typing/validation features we would define with it.
Tools can have some generic way to display and edit things without knowing what they're accessing.

But that advantage come at the cost of having a structure set in stone and too basic to support easily some extensions that may be more complex than key/value pairs.

I think our main goal for extensions is to allow users to define what they need for their tools. Not to try to allow tools not supporting those same extensions to somehow make use of them anyway. Interoperability is not the goal of extensions after all.

The list of additional attributes you are listing looks certainly useful. But it also looks like we are re-inventing features that are coming free with namespaces.

For example, with metaHolder we won't be able to validate the values of <meta> without a tool specifically designed for that. With custom namespace, any validator will handle it if you give it the schema.

I've been told users do not make their schemes available, but what make us sure those same users will make the effort of defining the type attribute in metaHolder?

Another advantage of using custom namespaces is that you can re-use them transparently in other XML containers (e.g. some internal proprietary formats). To me that is a big plus. More and more Web services and tools are providing way to "enrich" content in the language technology domain. Being able to re-use directly such annotations would be easier than trying to map them to metaHolder.

All the complaints I've seen for 1.2 were about extensions overlapping XLIFF features. The metaHolder solution does not address this better than custom namespace. There is no physical constraint we can put in XLIFF to prevent that, only conformance statements.

So it boils down to a choice of what we want the extensions to do in 2.0:

a) a limited way to have user-defined key/values pairs, with a limited validation mechanism, in restricted locations and limited to features not existing in XLIFF.

b) or a way to let users define the data they want with all the advantages provided by namespaces, also in restricted locations and limited to features not existing in XLIFF.

I think b) makes more sense.

Cheers,
-yves