Re: [xliff] Extensibility in Core and Modules

Ryan, Yves, all

I strongly disagree with this interpretation.

Reuse of module namespaces as extensions is NOT prohibited anywhere in the spec.

It just doesn't make sense to prohibit that.

We intended modules to be used at certain places but we did never ever prohibit *reusing their namespaces as extensions*. If people find mda useful at a general extension point that's great, especially if they don't want to specify and maintain their own namespace.. We might go and improve the status of mda at that extension point in the next version if more people find it useful.

Module namespaces reused at general extension points are simply not modules, even though their namespaces are XLIFF defined. Being XLIFF defined is a necessary but not a sufficient condition for something being a module. This is just a 2 and half thousand years old logical distinction..

There is no need to call INTENT because the logic of the spec is NOT equivocal and we MUST NOT invent additional constraints that are NOT specified in the standard.

@Yves, we went to great lengths to allow modules at specific extension points to ensure their status as MODULES (as opposed to extensions) at those extension points because their status was equivocal under XSD uniqueness rules.

This is a very good reason per se and no need to go looking for some mysterious additional intent.

Cheers

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 Sun, May 24, 2015 at 8:20 PM, Ryan King <ryanki@microsoft.com> wrote:

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,
Ryan

From: Yves Savourel
Sent: ‎5/‎24/‎2015 6:05 AM
To: XLIFF Main List
Subject: [xliff] Extensibility in Core and Modules

Hi 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.

Cheers,
-yves

---------------------------------------------------------------------
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

xliff message