[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]