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


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

 

 



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