[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Metadata extensibility with metaHolder
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]