RE: [xliff] Metadata extensibility with metaHolder

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

Hi Yves,

Just one quick comment:

|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 think your "equivalent in an imaginary namespace" example is problematic.

The attributes you show on your <ms:xxx> elements (as you have them marked up) are in the ms namespace (actually they are in no namespace, but that's a tricky concept). However, I think your intent is that they would be in the XLIFF namespace. For that to happen the attributes would need to be explicitly shifted to the XLIFF namespace, for example:

<ms:reviewComments xlf:path="data/comments" xlf:provider="MicrosoftLocABC">comments.csv</ms:reviewComments>

To make this happen (assuming the XLIFF schema sets it extensibility validation requirement to strict, or even lax), the ms schema needs to allow extensibility on any ms element that needs an XLIFF attribute. In most cases, I suspect, included schemas for namespaces will not support extensibility on elements we want to include in our XLIFF files. So let's assume the ms schema in your example does not allow extensibility on the elements used in the <unit> element. In this case your example will not be XML valid.

If in your example your intent is that the 'path', 'provider', etc. attributes are *not* in the XLIFF namespace, it is even more problematic. This would require the ms schema to actually have the those attributes in its content models (i.e., ms:path, ms:provider, etc.).

While I support the use of custom namespaces for extensibility (to augment the use of metaHolder), I fear that advocating *only* for custom namespaces sets us up for unexpected failures like the one above. I think a thorough analysis of the implications of "strict" and "lax" needs to take place before we consider using custom namespaces as our only extensibility mechanism (there are far more perplexing side effects than the one in this note).

- Bryan



-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Wednesday, May 16, 2012 6:36 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Metadata extensibility with metaHolder 

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



---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org