Hi all, please disregard my earlier reply. I agree 100% with Yves' ending statement: "We really need to clarify all this in 2.1." And until we do that, the default behavior for our OM will be to allow any elements from any namespace at any extension point in core or a module and ALWAYS preserve it. Which is probably the correct behavior for an OM anyway. From: Yves Savourel Sent: ?5/?23/?2015 5:06 PM To: 'Dr. David Filip' ; 'Soroush.Saadatfar' Cc:
xliff@lists.oasis-open.org Subject: RE: [xliff] RE: [QUAR] RE: [xliff] Extensibility in Modules Hi David, all, > saying that the modules are allowed explicitly means that they are > protected as *modules* at the given extension points where they are intended. I think this is not correct: Explicitly declaring the module somewhere does not protect them. What protect them is the PR that says: "An Agent processing a valid XLIFF Document that contains XLIFF-defined elements and attributes that it cannot handle MUST preserve those elements and attributes." A tool must preserve any un-supported XLIFF-defined element it finds, regardless where it finds it. > It does NOT mean that you cannot reuse module *namespaces* as > *extensions* where they were not explicitly allowed. Then I understand less and less the purpose of listing the modules in element's definition. It's not to mark them as 'protected'. Also why some modules are listing for some elements but not others? (like res in file but not in group). Also there the mailing list archive has a lot of discussion about this (like
https://lists.oasis-open.org/archives/xliff/201312/msg00077.html ). It looks like we wanted to forbid some modules in some extension points, but could not do it with the schema. > Any namespaces BUT XLIFF core (xlf) are allowed by the *other* wildcard > but only explicitly allowed modules are considered modules. That is not correct either: ##other allows any namespace but the namespace of the parent. So, technically <xlf:source> can be used in <gls:glossEntry>. The bottom line I think is that the schema is not powerful enough to express what we wanted to declare. > Module namespaces that are not explicitly listed behave > simply as extensions. > The only practical distinction between module and extension being > that modules MUST NOT be deleted and extensions SHOULD NOT be deleted. You are saying that a <mda:metadata> in a glossary would be an 'extension' and would not be protected. I think that is not correct: As stated in the PR above, the protection is not about 'module' or 'extension' but about XLIFF-defined element. Let's call a set of XLIFF-defined elements a module, but placing that module in a place where it's not explicitly listed doesn't change its PR: it must be preserved. We really need to clarify all this in 2.1. Cheers, -yves 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 Sat, May 23, 2015 at 7:33 PM, Soroush.Saadatfar <
Soroush.Saadatfar@ul.ie> wrote: As I did not contribute to XSD, I don't know how the schema behaves. So what is the valid scenario in this case you mentioned? I can then check the schema and add this part to NVDL if missing. Restrictions for the extension points are regulated only by XSD schema so far. Soroush. ----- Reply message ----- From: "Yves Savourel" <
ysavourel@enlaso.com> To: "XLIFF Main List" <
xliff@lists.oasis-open.org> Subject: [xliff] RE: [QUAR] RE: [xliff] Extensibility in Modules Date: Sat, May 23, 2015 6:27 PM Thanks for the explanation Soroush. So is that means that if I put an element of the res module in the extension point of <group> it will be seen as valid? (the schema says ‘##other’ so it should accept it) Or invalid (the specification does not list <res:resourceData> for group)? -ys From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ] On Behalf Of Soroush.Saadatfar Sent: Saturday, May 23, 2015 8:48 AM To:
xliff@lists.oasis-open.org Subject: Fwd: [xliff] RE: [QUAR] RE: [xliff] Extensibility in Modules Hi Yves! Actually NVDL handles modules. Extension points are defined and checked by the XSD schema, which is the first step of NVDL validation. Then NVDL applies appropriate Schematron rules to each module if they exist. So, in terms of "allowing" or "forbidding" extensions, XSD is in charge of this restrictions. ----- Forwarded message ----- From: "Soroush.Saadatfar" <
Soroush.Saadatfar@ul.ie> To: "Yves Savourel" <
ysavourel@enlaso.com> Subject: [xliff] RE: [QUAR] RE: [xliff] Extensibility in Modules Date: Sat, May 23, 2015 3:33 PM ----- Reply message ----- From: "Yves Savourel" <
ysavourel@enlaso.com> To: "XLIFF Main List" <
xliff@lists.oasis-open.org> Subject: [xliff] RE: [QUAR] RE: [xliff] Extensibility in Modules Date: Sat, May 23, 2015 2:25 PM 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 --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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