[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] RE: [QUAR] RE: [xliff] Extensibility in Modules
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]