OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xliff] Extensibility in Modules

Hi Ryan, all,


Interesting case.


The short answer is yes: the Metadata module can be used in the Glossary module extension point: nothing prevent it as far as I can tell, looking at the schema and the specification.


The only caveat I can think of is that--except for the PR that protects XLIFF-defined elements--you have to expect its support to be as for an extension rather than a module.


For example, a library that supports various modules can provide specific methods to access them. But it cannot be expected to completely treat as modules the modules that are used as extensions (i.e. present in extension points where they are not defined in the specification).


For instance our Okapi library supports, among others, the Translation Candidates, the Glossary and the Metadata modules. The Metadata modules is explicitly define in the Translation Candidates module, so our Match object as a getMetadata() method. But because the Glossary module does not define Metadata our GlossEntry object does not have a getMetadata() method. One would have to use the generic method for extensions getExtObject() instead. But that seems a minor issue.






From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King
Sent: Tuesday, May 19, 2015 11:16 AM
To: 'xliff@lists.oasis-open.org'
Subject: [xliff] Extensibility in Modules


Hello, TC members. As a follow-up to the TC call this morning, I would like some direction on encapsulating terminology in XLIFF 2.0. As stated in the spec:



*Simple* glossaries, consisting of a list of terms with a definition or translation, can be optionally embedded in an XLIFF document using the namespace mechanism to include elements from the Glossary module.


We have some *complex* terminology needs that cannot be encapsulated currently in the <gls:glossary> module. We have chosen, therefore, to use <mda:metadata> to encapsulate this data for better chance of interoperability instead of writing our own extension. Currently, this <mda:metadata> block is found at <unit> level. However, David Filip mentioned on the call that since <gls:glossary> was made extensible, it could contain <mda:metadata>. I want to confirm if the consensus is that this is indeed the case. The spec isn’t clear on this from my point of view. Here is what the spec says about extensibility:



4.9.1 Extension Points

The following XLIFF Core elements allow storing custom data in <mda:metadata> elements or in elements from a custom XML namespace:

- <file>

- <group>

- <unit>

[…] Extensibility of XLIFF Modules

For extensibility of XLIFF Modules please refer to the relevant Module Sections.


So, it is explicit in 4.9.1 that <mda:metadata> can only be used in <file>, <group>. And <unit> in core. To determine, the use of <mda:metadata> in modules, refers me to the relevant module. In this case, <gls:glossary>, which does NOT explicitly state that <mda:metadata> can be used:




+---<glossEntry> +


  +---<term> 1


  +---<translation> *


  +---<definition> ?


  +---<other> *


However, <mtc:matches> does explicitly state it, and in fact, it is the only module that does:




+---<match> +


  +---<mda:metadata> ?


  +---<xlf:originalData> ?


  +---<xlf:source> 1


  +---<xlf:target> 1


  +---<other> *


So, does the use of <mda:metadata> in a module require it to be explicitly called out as it is in core and <mtc:matches> or can <mda:metadata> be treated like any extension and be found where <other> is specified?






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]