RE: [xliff] Metadata extensibility with metaHolder

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

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