[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] Extensibility in Core and Modules
Hi Yves, David, Soroush, all,
I think Yves logic here makes sense with the way the spec has been written (even if the intent was something different). So, until we can discuss further and make possible clarifications in 2.1, the safest interpretation for implementing 2.0 is the literal one: Extensions can appear at any extension point, but Modules can only appear where they are explicitly called out, which makes my use case not optimal, but still manageable (I'll have example implementations in Berlin).
Thanks all for the discussion,
RyanHi David, Ryan, Soroush, all,
Maybe a good way to clarify whether or not any modules can be in an extension point is to look at an example:
Currently the <res:resourceData> element is not listed in the <group> element. Can a user still add one anyway? The schema uses ##other and allows it, and AFAIK there is no *explicit text* in the specification that says it cannot be placed in <group>.
== A) If the answer is "yes <res:resourceData> can be added in <group>" then:
-A.1) Why did we bother to list some modules in <group> (and other elements)?
-A.2) Why did we seem to go to great lengths to somehow indicate which modules could go in which extension point?
(As shown for example in https://lists.oasis-open.org/archives/xliff/201312/msg00077.html)
== B) If the answer is "no <res:resourceData> cannot be added in <group>" then:
- B.1) That probably means <mda:metadata> should not be used in <gls:glossEntry> either. Because the pattern is the same: ##other in the schema, and modules using modules list them explicitly (like <mda:metadata> in <mtc:match>)
I would tend to think the answer to the question is "no" (A).
I think that because if the answer is "yes", I can't find a rational explanation for A.1 and A2.
Also, in the Matches module: the <mda:metadata> element is declared outside the extension point. If we were to put a <mda:metadata> in glossary it could only be at the extension point. And that would be really strange to have such difference.
So I think that by listing the modules in the specification we did meant to list those that were allowed.
Note also that there was a discussion about having a <mda:metadata> in the glossary in 2012: https://lists.oasis-open.org/archives/xliff/201211/msg00111.html (It looks eerily similar to the one of this week-end: https://lists.oasis-open.org/archives/xliff/201505/msg00016.html). There was apparently no follow-up conclusion in 2012, which led by default to no <mda:metadata> in glossary.
Regardless of the merit of <mda:metadata> in modules, I'm glad Ryan brought up the issue, because either ways, the specification really needs to be clarify on the topic of modules in extension points. Hopefully that can be done during the F2F meeting.
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: