RE: [xliff] Metadata extensibility with metaHolder

[Yves Savourel <ysavourel@enlaso.com>]

Hi Rodolfo,

Indeed, I mistakenly inverted <segment> and <source>.
It should be the other way around.

<unit id='1'>
 <segment>
  <source>Some text</source>
  <metaHolder>
  ...
  </metaHolder>
 </segment>
</unit>

And I agree: we should have extensions in <source> (whether metaHolder or custom namespace.

Thanks for the correction.

Cheers,
-yves


-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya
Sent: Wednesday, May 16, 2012 8:14 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Metadata extensibility with metaHolder 

Yves,

The examples included in your message don't follow the structure we have so far:

<unit>
  <segment>
    <source> text </source>
  </segment>
</unit>

Your examples put <segment> inside <source> and also place custom extensions inside <source>.

In my opinion, it is a very bad idea to place custom extensions of any kind inside <source>.

Regards,
Rodolfo
--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms       http://www.maxprograms.com


> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] 
> On Behalf Of Yves Savourel
> Sent: Wednesday, May 16, 2012 10: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



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