OASIS XML Localisation Interchange File Format (XLIFF) TC

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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#glossary-module * 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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#extensions 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> […] 4.9.1.1 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, 4.9.1.1 refers me to the relevant module. In this case, <gls:glossary>, which does NOT explicitly state that <mda:metadata> can be used:   <glossary> +---<glossEntry> +     +---<term> 1     +---<translation> *     +---<definition> ?     +---<other> *   However, <mtc:matches> does explicitly state it, and in fact, it is the only module that does:   <matches> +---<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?   Thanks, Ryan    

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.   Cheers, -yves     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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#glossary-module * 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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#extensions 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> […] 4.9.1.1 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, 4.9.1.1 refers me to the relevant module. In this case, <gls:glossary>, which does NOT explicitly state that <mda:metadata> can be used:   <glossary> +---<glossEntry> +     +---<term> 1     +---<translation> *     +---<definition> ?     +---<other> *   However, <mtc:matches> does explicitly state it, and in fact, it is the only module that does:   <matches> +---<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?   Thanks, Ryan    

Thanks, Yves, Ryan On Tue, May 19, 2015 at 8:24 PM, Yves Savourel < ysavourel@enlaso.com > wrote: 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. Exactly, that's what I also said in the meeting ;-) [but we had a bad feedback between myself and Ryan, so it might have broken up] I guess, Ryan, and others might benefit from allowing the mda explicitly in Glossary. On the other hand, if Ryan and MSFT are just looking into a way to include metadata in the glossary module w/o defining their own namespace for it, the mda is as good as any other namespace. The question is I guess, if MSFT expect a third party to process and roundtrip the mda based metadata that they put in the glossary module. It's probably worth looking at the detailed use case to tell if the mda is in need of module handling rather than extension handling at the Glossary extension points.. Anyways, using mda to completely replace gls violates the high level PR saying that user defined extensibility, no matter if mda or custom namespace based, must not be used instead of a core or module feature. Cheers dF Dr. David Filip ======================= OASIS XLIFF TC Secretary, Editor, and Liaison Officer  LRC CNGL CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto:  david.filip@ul.ie

>>
Anyways, using mda to completely replace gls violates the high level PR saying that user defined extensibility, no matter if mda or custom namespace based, must not be used instead of a core or module feature.
 
David, I might argue that with you. The spec states that the <gls:glossary> module is for used for “*Simple* glossaries, consisting of a list of terms with a
definition or translation”, my terminology needs are not simple and extend beyond a list of terms with definition and translation.
 
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Dr. David Filip
Sent: Tuesday, May 19, 2015 12:53 PM
To: Yves Savourel
Cc: XLIFF Main List
Subject: Re: [xliff] Extensibility in Modules
 


Thanks, Yves, Ryan

On Tue, May 19, 2015 at 8:24 PM, Yves Savourel < ysavourel@enlaso.com > wrote:

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.


Exactly, that's what I also said in the meeting ;-) [but we had a bad feedback between myself and Ryan, so it might have broken up]


I guess, Ryan, and others might benefit from allowing the mda explicitly in Glossary.


On the other hand, if Ryan and MSFT are just looking into a way to include metadata in the glossary module w/o defining their own namespace for it, the mda is as good as any other namespace.


The question is I guess, if MSFT expect a third party to process and roundtrip the mda based metadata that they put in the glossary module.


It's probably worth looking at the detailed use case to tell if the mda is in need of module handling rather than extension handling at the Glossary extension points..


 


Anyways, using mda to completely replace gls violates the high level PR saying that user defined extensibility, no matter if mda or custom namespace based, must not be used instead of a core or module feature.


 


Cheers


dF











Dr. David Filip







=======================

OASIS XLIFF TC Secretary, Editor, and Liaison Officer 


LRC CNGL CSIS


University of Limerick, Ireland


telephone: +353-6120-2781


cellphone: +353-86-0222-158


facsimile: +353-6120-2734


http://www.cngl.ie/profile/?i=452


mailto:  david.filip@ul.ie

Ryan, I don't want to be dogmatic here But if you want to transfer terminology in your package, you should use the gls as the baseline to promote interoperability. Other people will be able to use at least the simple goodness without building support specifically for your terminology in mda. If anytime you think are more feature rich than what is in the module, you are going to replace it with a proprietary mda construct, we are going again down the XLIFF 1.2 extensibility route mda although a module is just an extension mechanism that does not allow for specification of any business logic No one can really consume your mda based terminology as terminology gls is tied to the core annotation mechanism and can be used for term lifecycle mgmt while terminology is in the XLIFF facilitated roundtrip Outside of the XLIFF roundtrip terminology is supposed to live in TBs i.e. outside of XLIFF scope.. I think that the gls has a basic terminology roundtrip logic (tied to core) that gives you a terminology specifc baseline that the mda can never express. All your structures that don't fit the gls you can transfer from your core extension point to the gls extension points. If you feel that the data isn't safe there, you can suggest explicitly listing mda at those gls extension points.. I think this would be a minor change that would cause no harm.. would work for any XLIFF 2, and from 2.1 it would be treated as a guaranteed module. Cheers dF Cheers dF Cheers dF Dr. David Filip ======================= OASIS XLIFF TC Secretary, Editor, and Liaison Officer  LRC CNGL CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto:  david.filip@ul.ie On Tue, May 19, 2015 at 9:24 PM, Ryan King < ryanki@microsoft.com > wrote: >> Anyways, using mda to completely replace gls violates the high level PR saying that user defined extensibility, no matter if mda or custom namespace based, must not be used instead of a core or module feature.   David, I might argue that with you. The spec states that the <gls:glossary> module is for used for “*Simple* glossaries, consisting of a list of terms with a definition or translation”, my terminology needs are not simple and extend beyond a list of terms with definition and translation.   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Dr. David Filip Sent: Tuesday, May 19, 2015 12:53 PM To: Yves Savourel Cc: XLIFF Main List Subject: Re: [xliff] Extensibility in Modules   Thanks, Yves, Ryan On Tue, May 19, 2015 at 8:24 PM, Yves Savourel < ysavourel@enlaso.com > wrote: 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. Exactly, that's what I also said in the meeting ;-) [but we had a bad feedback between myself and Ryan, so it might have broken up] I guess, Ryan, and others might benefit from allowing the mda explicitly in Glossary. On the other hand, if Ryan and MSFT are just looking into a way to include metadata in the glossary module w/o defining their own namespace for it, the mda is as good as any other namespace. The question is I guess, if MSFT expect a third party to process and roundtrip the mda based metadata that they put in the glossary module. It's probably worth looking at the detailed use case to tell if the mda is in need of module handling rather than extension handling at the Glossary extension points..   Anyways, using mda to completely replace gls violates the high level PR saying that user defined extensibility, no matter if mda or custom namespace based, must not be used instead of a core or module feature.   Cheers dF Dr. David Filip ======================= OASIS XLIFF TC Secretary, Editor, and Liaison Officer  LRC CNGL CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto:  david.filip@ul.ie

Thanks David for the reply. Of course, you are right on all points. Playing devil’s advocate, I just think the spec itself can be interpreted differently since
it does not clearly state what you just stated below. * Simple * and * Glossary * can be interpreted quite different from * complex * and * terminology * in my dataset. In any case, we will support <mda:metadata> on <gls:glossary> as an
extension in true spirit of standards and interoperability. And I’m not worried about it being removed, although some implementers might. Again, it’s too bad that there isn’t consistency in the spec on how to deal with <mda:metadata> as a module or as an extension
overall, not just in <gls:glossary>.  
 
From: Dr. David Filip [mailto:David.Filip@ul.ie]

Sent: Tuesday, May 19, 2015 1:55 PM
To: Ryan King
Cc: Dr. David Filip; Yves Savourel; XLIFF Main List
Subject: Re: [xliff] Extensibility in Modules
 

Ryan, I don't want to be dogmatic here

But if you want to transfer terminology in your package, you should use the gls as the baseline to promote interoperability. Other people will be able to use at least the simple goodness without building support specifically for your terminology
in mda.


If anytime you think are more feature rich than what is in the module, you are going to replace it with a proprietary mda construct, we are going again down the XLIFF 1.2 extensibility route


 


mda although a module is just an extension mechanism that does not allow for specification of any business logic


 


No one can really consume your mda based terminology as terminology


 


gls is tied to the core annotation mechanism and can be used for term lifecycle mgmt while terminology is in the XLIFF facilitated roundtrip


 


Outside of the XLIFF roundtrip terminology is supposed to live in TBs i.e. outside of XLIFF scope..


 


I think that the gls has a basic terminology roundtrip logic (tied to core) that gives you a terminology specifc baseline that the mda can never express.


All your structures that don't fit the gls you can transfer from your core extension point to the gls extension points.


 


If you feel that the data isn't safe there, you can suggest explicitly listing mda at those gls extension points.. I think this would be a minor change that would cause no harm.. would work for any XLIFF 2, and from 2.1 it would be treated
as a guaranteed module.


 


Cheers


dF


 


Cheers


dF


 


Cheers


dF










Dr. David Filip







=======================

OASIS XLIFF TC Secretary, Editor, and Liaison Officer 


LRC CNGL CSIS


University of Limerick, Ireland


telephone: +353-6120-2781


cellphone: +353-86-0222-158


facsimile: +353-6120-2734


http://www.cngl.ie/profile/?i=452


mailto:  david.filip@ul.ie









 

On Tue, May 19, 2015 at 9:24 PM, Ryan King < ryanki@microsoft.com > wrote:



>>
Anyways, using mda to completely replace gls violates the high level PR saying that user defined extensibility, no matter if mda or custom namespace based, must not be used instead of a core or module feature.
 
David, I might argue that with you. The spec states that the <gls:glossary> module is for used for
“*Simple* glossaries, consisting of a list of terms with a definition or translation”, my terminology needs are not simple and extend beyond a list of terms with definition and translation.
 
From:
xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ]
On Behalf Of Dr. David Filip
Sent: Tuesday, May 19, 2015 12:53 PM
To: Yves Savourel
Cc: XLIFF Main List
Subject: Re: [xliff] Extensibility in Modules


 


Thanks, Yves, Ryan

On Tue, May 19, 2015 at 8:24 PM, Yves Savourel < ysavourel@enlaso.com > wrote:

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.


Exactly, that's what I also said in the meeting ;-) [but we had a bad feedback between myself and Ryan, so it might have broken up]


I guess, Ryan, and others might benefit from allowing the mda explicitly in Glossary.


On the other hand, if Ryan and MSFT are just looking into a way to include metadata in the glossary module w/o defining their own namespace for it, the mda is as good as any other
namespace.


The question is I guess, if MSFT expect a third party to process and roundtrip the mda based metadata that they put in the glossary module.


It's probably worth looking at the detailed use case to tell if the mda is in need of module handling rather than extension handling at the Glossary extension points..


 


Anyways, using mda to completely replace gls violates the high level PR saying that user defined extensibility, no matter if mda or custom namespace based, must not be used instead
of a core or module feature.


 


Cheers


dF











Dr. David Filip







=======================

OASIS XLIFF TC Secretary, Editor, and Liaison Officer 


LRC CNGL CSIS


University of Limerick, Ireland


telephone: +353-6120-2781


cellphone: +353-86-0222-158


facsimile: +353-6120-2734


http://www.cngl.ie/profile/?i=452


mailto:  david.filip@ul.ie

















 

Hi Yves, all,   >> 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.   This is exactly the information I needed. Good to see how you would implemented in in OKAPI, we have to do the exact same in our OM. It is just unfortunate that there is not consistency in the spec on how to deal with <mda:metadata> as a module or an extension…and it is probably not clear to implementers that don’t have the benefit of asking the TC this question…     From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel Sent: Tuesday, May 19, 2015 12:25 PM To: XLIFF Main List 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.   Cheers, -yves     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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#glossary-module * 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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#extensions 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> […] 4.9.1.1 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, 4.9.1.1 refers me to the relevant module. In this case, <gls:glossary>, which does NOT explicitly state that <mda:metadata> can be used:   <glossary> +---<glossEntry> +     +---<term> 1     +---<translation> *     +---<definition> ?     +---<other> *   However, <mtc:matches> does explicitly state it, and in fact, it is the only module that does:   <matches> +---<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?   Thanks, Ryan    

On Tue, May 19, 2015 at 9:21 PM, Ryan King < ryanki@microsoft.com > wrote: This is exactly the information I needed. Good to see how you would implemented in in OKAPI, we have to do the exact same in our OM. It is just unfortunate that there is not consistency in the spec on how to deal with <mda:metadata> as a module or an extension…and it is probably not clear to implementers that don’t have the benefit of asking the TC this question… Ryan, every developer can ask the TC via the comments list  xliff-comment@lists.oasis-open.org   https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=xliff Of course the goal is as clear as possible Also there is no ambiguity or inconsistency in that.. mda is allowed *as module* at the core extension points and at 1 extension point in Translation Candidates Any module can be used *as an extension* at any extension point in the spec. This is not a special case for mda mda is more susceptible to be used at extension points where it wasn't explicitly allowed because it's a catch all feature and handy for people who just want to throw in a bunch of metadata without inventing their own custom namespaces Cheers dF Cheers dF Dr. David Filip ======================= OASIS XLIFF TC Secretary, Editor, and Liaison Officer  LRC CNGL CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto:  david.filip@ul.ie

>>Also there is no ambiguity or inconsistency in that..
 
I didn’t argue ambiguity, I argued inconsistency. And yes, there is inconsistency when you look at implementation. It is exactly what Yves stated below: “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.”
 
This will not be readily apparent to developers and not all developers know about, or will ask the TC via the comments list.
 
Also, I’m not sure why you think that a custom extension is somehow more interoperable than metadata. At best, only me and my customers will know how to deal
with my custom extension, but if I use metadata, at least everyone who supports the metadata module will be able to view/display the data.

 
But in the end, I agree with you that using <gls:glossary> as a baseline is the correct thing to do.
 
Thanks,
Ryan
 
From: Dr. David Filip [mailto:David.Filip@ul.ie]

Sent: Tuesday, May 19, 2015 1:41 PM
To: Ryan King
Cc: Yves Savourel; XLIFF Main List
Subject: Re: [xliff] Extensibility in Modules
 


 

On Tue, May 19, 2015 at 9:21 PM, Ryan King < ryanki@microsoft.com > wrote:

This is exactly the information I needed. Good to see how you would implemented in in OKAPI, we have to do the exact same in our OM. It is just unfortunate that there is not consistency in the spec on how to deal with <mda:metadata> as
a module or an extension…and it is probably not clear to implementers that don’t have the benefit of asking the TC this question…



Ryan, every developer can ask the TC via the comments list  xliff-comment@lists.oasis-open.org  


https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=xliff


 


Of course the goal is as clear as possible


 


Also there is no ambiguity or inconsistency in that..


 


mda is allowed *as module* at the core extension points and at 1 extension point in Translation Candidates


 


Any module can be used *as an extension* at any extension point in the spec. This is not a special case for mda


 


mda is more susceptible to be used at extension points where it wasn't explicitly allowed because it's a catch all feature and handy for people who just want to throw in a bunch of metadata without inventing their own custom namespaces


 


Cheers


dF


 


Cheers


dF


 










Dr. David Filip







=======================

OASIS XLIFF TC Secretary, Editor, and Liaison Officer 


LRC CNGL CSIS


University of Limerick, Ireland


telephone: +353-6120-2781


cellphone: +353-86-0222-158


facsimile: +353-6120-2734


http://www.cngl.ie/profile/?i=452


mailto:  david.filip@ul.ie

Hi Yves, all,   Sorry to be coming back to this thread, re:   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.   So if I understood you correctly, Yves, I should be able to do the following:        <gls:glossary>        <gls:glossEntry id="g1">         <gls:term>failed</gls:term>         <gls:translation id="target-term-1">ausgefallen</gls:translation>         <mda:metadata>          <mda:metaGroup category="terminology">           <mda:meta type="concept-id">15910</mda:meta>          </mda:metaGroup>         </mda:metadata>        </gls:glossEntry>       </gls:glossary>   Yet, in your validator located at http://okapi-lynx.appspot.com/validation , I get the following error:   Error in <file> id='f1', <unit> id='u1' Last element read: '{urn:oasis:names:tc:xliff:metadata:2.0}metadata': No modules are allowed in 'gls:glossEntry'.   Please advise. Is my only recourse then to create my own custom extension in <gls:glossary> to encapsulate my “concept-id”?   Thanks, Ryan   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King Sent: Tuesday, May 19, 2015 1:22 PM To: Yves Savourel; XLIFF Main List Subject: RE: [xliff] Extensibility in Modules   Hi Yves, all,   >> 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.   This is exactly the information I needed. Good to see how you would implemented in in OKAPI, we have to do the exact same in our OM. It is just unfortunate that there is not consistency in the spec on how to deal with <mda:metadata> as a module or an extension…and it is probably not clear to implementers that don’t have the benefit of asking the TC this question…     From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Tuesday, May 19, 2015 12:25 PM To: XLIFF Main List 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.   Cheers, -yves     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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#glossary-module * 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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#extensions 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> […] 4.9.1.1 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, 4.9.1.1 refers me to the relevant module. In this case, <gls:glossary>, which does NOT explicitly state that <mda:metadata> can be used:   <glossary> +---<glossEntry> +     +---<term> 1     +---<translation> *     +---<definition> ?     +---<other> *   However, <mtc:matches> does explicitly state it, and in fact, it is the only module that does:   <matches> +---<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?   Thanks, Ryan    

Yes, it looks like being over-strict in the validation. Basically currently the tool would see the element as valid if it wasn’t an XLIFF namespace. When it’s an XLIFF namespace it goes through extra check but only if it was declared in the spec. So I need to change this and allow non-declared modules as extension. I’m not quite sure what side effect this will have on the code… I’ll work on it this week-end.   -ys     From: Ryan King [mailto:ryanki@microsoft.com] Sent: Friday, May 22, 2015 4:42 PM To: Ryan King; Yves Savourel; XLIFF Main List Subject: RE: [xliff] Extensibility in Modules   Hi Yves, all,   Sorry to be coming back to this thread, re:   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.   So if I understood you correctly, Yves, I should be able to do the following:        <gls:glossary>        <gls:glossEntry id="g1">         <gls:term>failed</gls:term>         <gls:translation id="target-term-1">ausgefallen</gls:translation>         <mda:metadata>          <mda:metaGroup category="terminology">           <mda:meta type="concept-id">15910</mda:meta>          </mda:metaGroup>         </mda:metadata>        </gls:glossEntry>       </gls:glossary>   Yet, in your validator located at http://okapi-lynx.appspot.com/validation , I get the following error:   Error in <file> id='f1', <unit> id='u1' Last element read: '{urn:oasis:names:tc:xliff:metadata:2.0}metadata': No modules are allowed in 'gls:glossEntry'.   Please advise. Is my only recourse then to create my own custom extension in <gls:glossary> to encapsulate my “concept-id”?   Thanks, Ryan   From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Ryan King Sent: Tuesday, May 19, 2015 1:22 PM To: Yves Savourel; XLIFF Main List Subject: RE: [xliff] Extensibility in Modules   Hi Yves, all,   >> 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.   This is exactly the information I needed. Good to see how you would implemented in in OKAPI, we have to do the exact same in our OM. It is just unfortunate that there is not consistency in the spec on how to deal with <mda:metadata> as a module or an extension…and it is probably not clear to implementers that don’t have the benefit of asking the TC this question…     From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Tuesday, May 19, 2015 12:25 PM To: XLIFF Main List 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.   Cheers, -yves     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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#glossary-module * 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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#extensions 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> […] 4.9.1.1 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, 4.9.1.1 refers me to the relevant module. In this case, <gls:glossary>, which does NOT explicitly state that <mda:metadata> can be used:   <glossary> +---<glossEntry> +     +---<term> 1     +---<translation> *     +---<definition> ?     +---<other> *   However, <mtc:matches> does explicitly state it, and in fact, it is the only module that does:   <matches> +---<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?   Thanks, Ryan    

Ok, thanks for confirming. It's important that I understand this so that our OM implementation is correct. One last confirmation of my understanding. Per 4.2.2.2 and 4.9.1 File can contain any custom extension, but only ctr, mda, res, slr, and val modules. Per 4.2.2.4 and 4.9.1 Group can contain any  custom extension, but only ctr, mda, slr, and val modules Per 4.2.2.5 and 4.9.1 Unit can contain any custom extension and any module. And finally, any module can contain any custom extension and any other module. Is that all correct? From: Yves Savourel Sent: ?5/?22/?2015 7:26 PM To: XLIFF Main List Subject: RE: [xliff] Extensibility in Modules Yes, it looks like being over-strict in the validation. Basically currently the tool would see the element as valid if it wasn’t an XLIFF namespace. When it’s an XLIFF namespace it goes through extra check but only if it was declared in the spec. So I need to change this and allow non-declared modules as extension. I’m not quite sure what side effect this will have on the code… I’ll work on it this week-end.   -ys     From: Ryan King [mailto:ryanki@microsoft.com] Sent: Friday, May 22, 2015 4:42 PM To: Ryan King; Yves Savourel; XLIFF Main List Subject: RE: [xliff] Extensibility in Modules   Hi Yves, all,   Sorry to be coming back to this thread, re:   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.   So if I understood you correctly, Yves, I should be able to do the following:        <gls:glossary>        <gls:glossEntry id="g1">         <gls:term>failed</gls:term>         <gls:translation id="target-term-1">ausgefallen</gls:translation>         <mda:metadata>          <mda:metaGroup category="terminology">           <mda:meta type="concept-id">15910</mda:meta>          </mda:metaGroup>         </mda:metadata>        </gls:glossEntry>       </gls:glossary>   Yet, in your validator located at http://okapi-lynx.appspot.com/validation , I get the following error:   Error in <file> id='f1', <unit> id='u1' Last element read: '{urn:oasis:names:tc:xliff:metadata:2.0}metadata': No modules are allowed in 'gls:glossEntry'.   Please advise. Is my only recourse then to create my own custom extension in <gls:glossary> to encapsulate my “concept-id”?   Thanks, Ryan   From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Ryan King Sent: Tuesday, May 19, 2015 1:22 PM To: Yves Savourel; XLIFF Main List Subject: RE: [xliff] Extensibility in Modules   Hi Yves, all,   >> 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.   This is exactly the information I needed. Good to see how you would implemented in in OKAPI, we have to do the exact same in our OM. It is just unfortunate that there is not consistency in the spec on how to deal with <mda:metadata> as a module or an extension…and it is probably not clear to implementers that don’t have the benefit of asking the TC this question…     From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Tuesday, May 19, 2015 12:25 PM To: XLIFF Main List 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.   Cheers, -yves     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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#glossary-module * 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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#extensions 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> […] 4.9.1.1 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, 4.9.1.1 refers me to the relevant module. In this case, <gls:glossary>, which does NOT explicitly state that <mda:metadata> can be used:   <glossary> +---<glossEntry> +     +---<term> 1     +---<translation> *     +---<definition> ?     +---<other> *   However, <mtc:matches> does explicitly state it, and in fact, it is the only module that does:   <matches> +---<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?   Thanks, Ryan    

Hum… Maybe the validator meant to be like it is. I think I was wrong to say any module is allowed in the extension points. I was saying that based on the schema, but forgot that the schema cannot enforce all constraints. The sentences "The following XLIFF Module elements are explicitly allowed by the wildcard other" in the specification and the email discussion (for example https://lists.oasis-open.org/archives/xliff/201312/msg00077.html ) seem to indicate that the intent was to limit the modules useable in the extension points, but could not be done in the schema (See review comment 138: https://lists.oasis-open.org/archives/xliff-comment/201310/msg00025.html ) I wish that was a bit clearer in the text of the specification. It seems we meant to say: "The following XLIFF Module elements are allowed, while the other modules are not (despite being implicitly allowed by the wildcard other in the schema)" Is that correct or not? The extensions in the modules are even less clear. Presumably, it should be written like for the core: if the module is not listed it's not allowed. It's even more specific because the only module where there is another module is Matches that declares Metadata. And in that case, the Metadata element is allowed explicitly in the schema, because it is (unlike in the core) separated from the extension point. So, logically, we would have done the same in Glossary if Metadata was meant to be allowed there. At the same time, nothing in the specification says we can't put it in the extension point and the schema allows it. So I don't know what is correct. -ys From: Ryan King [ mailto:ryanki@microsoft.com ] Sent: Friday, May 22, 2015 10:47 PM To: Yves Savourel; XLIFF Main List Subject: [QUAR] RE: [xliff] Extensibility in Modules Ok, thanks for confirming. It's important that I understand this so that our OM implementation is correct. One last confirmation of my understanding. Per 4.2.2.2 and 4.9.1 File can contain any custom extension, but only ctr, mda, res, slr, and val modules. Per 4.2.2.4 and 4.9.1 Group can contain any  custom extension, but only ctr, mda, slr, and val modules Per 4.2.2.5 and 4.9.1 Unit can contain any custom extension and any module. And finally, any module can contain any custom extension and any other module. Is that all correct? ________________________________________ From: Yves Savourel Sent: ?5/?22/?2015 7:26 PM To: XLIFF Main List Subject: RE: [xliff] Extensibility in Modules Yes, it looks like being over-strict in the validation. Basically currently the tool would see the element as valid if it wasn’t an XLIFF namespace. When it’s an XLIFF namespace it goes through extra check but only if it was declared in the spec. So I need to change this and allow non-declared modules as extension. I’m not quite sure what side effect this will have on the code… I’ll work on it this week-end.   -ys     From: Ryan King [ mailto:ryanki@microsoft.com ] Sent: Friday, May 22, 2015 4:42 PM To: Ryan King; Yves Savourel; XLIFF Main List Subject: RE: [xliff] Extensibility in Modules   Hi Yves, all,   Sorry to be coming back to this thread, re:   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.   So if I understood you correctly, Yves, I should be able to do the following:        <gls:glossary>        <gls:glossEntry id="g1">         <gls:term>failed</gls:term>         <gls:translation id="target-term-1">ausgefallen</gls:translation>         <mda:metadata>          <mda:metaGroup category="terminology">           <mda:meta type="concept-id">15910</mda:meta>          </mda:metaGroup>         </mda:metadata>        </gls:glossEntry>       </gls:glossary>   Yet, in your validator located at http://okapi-lynx.appspot.com/validation , I get the following error:   Error in <file> id='f1', <unit> id='u1' Last element read: '{urn:oasis:names:tc:xliff:metadata:2.0}metadata': No modules are allowed in 'gls:glossEntry'.   Please advise. Is my only recourse then to create my own custom extension in <gls:glossary> to encapsulate my “concept-id”?   Thanks, Ryan   From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Ryan King Sent: Tuesday, May 19, 2015 1:22 PM To: Yves Savourel; XLIFF Main List Subject: RE: [xliff] Extensibility in Modules   Hi Yves, all,   >> 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.   This is exactly the information I needed. Good to see how you would implemented in in OKAPI, we have to do the exact same in our OM. It is just unfortunate that there is not consistency in the spec on how to deal with <mda:metadata> as a module or an extension…and it is probably not clear to implementers that don’t have the benefit of asking the TC this question…     From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Tuesday, May 19, 2015 12:25 PM To: XLIFF Main List 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.   Cheers, -yves     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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#glossary-module *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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#extensions 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> […] 4.9.1.1 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, 4.9.1.1 refers me to the relevant module. In this case, <gls:glossary>, which does NOT explicitly state that <mda:metadata> can be used:   <glossary> +---<glossEntry> +     +---<term> 1     +---<translation> *     +---<definition> ?     +---<other> *   However, <mtc:matches> does explicitly state it, and in fact, it is the only module that does:   <matches> +---<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?   Thanks, Ryan    

Hi Soroush, What does the Schematron validation tool does about modules in the modules' extension points? And in the core's ones? Thanks, -ys
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Saturday, May 23, 2015 6:58 AM To: XLIFF Main List Subject: [xliff] RE: [QUAR] RE: [xliff] Extensibility in Modules Hum… Maybe the validator meant to be like it is. I think I was wrong to say any module is allowed in the extension points. I was saying that based on the schema, but forgot that the schema cannot enforce all constraints. The sentences "The following XLIFF Module elements are explicitly allowed by the wildcard other" in the specification and the email discussion (for example https://lists.oasis-open.org/archives/xliff/201312/msg00077.html ) seem to indicate that the intent was to limit the modules useable in the extension points, but could not be done in the schema (See review comment 138: https://lists.oasis-open.org/archives/xliff-comment/201310/msg00025.html ) I wish that was a bit clearer in the text of the specification. It seems we meant to say: "The following XLIFF Module elements are allowed, while the other modules are not (despite being implicitly allowed by the wildcard other in the schema)" Is that correct or not? The extensions in the modules are even less clear. Presumably, it should be written like for the core: if the module is not listed it's not allowed. It's even more specific because the only module where there is another module is Matches that declares Metadata. And in that case, the Metadata element is allowed explicitly in the schema, because it is (unlike in the core) separated from the extension point. So, logically, we would have done the same in Glossary if Metadata was meant to be allowed there. At the same time, nothing in the specification says we can't put it in the extension point and the schema allows it. So I don't know what is correct. -ys From: Ryan King [ mailto:ryanki@microsoft.com ] Sent: Friday, May 22, 2015 10:47 PM To: Yves Savourel; XLIFF Main List Subject: [QUAR] RE: [xliff] Extensibility in Modules Ok, thanks for confirming. It's important that I understand this so that our OM implementation is correct. One last confirmation of my understanding. Per 4.2.2.2 and 4.9.1 File can contain any custom extension, but only ctr, mda, res, slr, and val modules. Per 4.2.2.4 and 4.9.1 Group can contain any  custom extension, but only ctr, mda, slr, and val modules Per 4.2.2.5 and 4.9.1 Unit can contain any custom extension and any module. And finally, any module can contain any custom extension and any other module. Is that all correct? ________________________________________ From: Yves Savourel Sent: ?5/?22/?2015 7:26 PM To: XLIFF Main List Subject: RE: [xliff] Extensibility in Modules Yes, it looks like being over-strict in the validation. Basically currently the tool would see the element as valid if it wasn’t an XLIFF namespace. When it’s an XLIFF namespace it goes through extra check but only if it was declared in the spec. So I need to change this and allow non-declared modules as extension. I’m not quite sure what side effect this will have on the code… I’ll work on it this week-end.   -ys     From: Ryan King [ mailto:ryanki@microsoft.com ] Sent: Friday, May 22, 2015 4:42 PM To: Ryan King; Yves Savourel; XLIFF Main List Subject: RE: [xliff] Extensibility in Modules   Hi Yves, all,   Sorry to be coming back to this thread, re:   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.   So if I understood you correctly, Yves, I should be able to do the following:        <gls:glossary>        <gls:glossEntry id="g1">         <gls:term>failed</gls:term>         <gls:translation id="target-term-1">ausgefallen</gls:translation>         <mda:metadata>          <mda:metaGroup category="terminology">           <mda:meta type="concept-id">15910</mda:meta>          </mda:metaGroup>         </mda:metadata>        </gls:glossEntry>       </gls:glossary>   Yet, in your validator located at http://okapi-lynx.appspot.com/validation , I get the following error:   Error in <file> id='f1', <unit> id='u1' Last element read: '{urn:oasis:names:tc:xliff:metadata:2.0}metadata': No modules are allowed in 'gls:glossEntry'.   Please advise. Is my only recourse then to create my own custom extension in <gls:glossary> to encapsulate my “concept-id”?   Thanks, Ryan   From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Ryan King Sent: Tuesday, May 19, 2015 1:22 PM To: Yves Savourel; XLIFF Main List Subject: RE: [xliff] Extensibility in Modules   Hi Yves, all,   >> 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.   This is exactly the information I needed. Good to see how you would implemented in in OKAPI, we have to do the exact same in our OM. It is just unfortunate that there is not consistency in the spec on how to deal with <mda:metadata> as a module or an extension…and it is probably not clear to implementers that don’t have the benefit of asking the TC this question…     From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Tuesday, May 19, 2015 12:25 PM To: XLIFF Main List 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.   Cheers, -yves     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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#glossary-module *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:   http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#extensions 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> […] 4.9.1.1 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, 4.9.1.1 refers me to the relevant module. In this case, <gls:glossary>, which does NOT explicitly state that <mda:metadata> can be used:   <glossary> +---<glossEntry> +     +---<term> 1     +---<translation> *     +---<definition> ?     +---<other> *   However, <mtc:matches> does explicitly state it, and in fact, it is the only module that does:   <matches> +---<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?   Thanks, Ryan     --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php