Thanks David, I will have some examples of how we would need to implement this if mda were not allowed in gls, and how we would implement if it were. I haven’t
had time to look at the TBX mapping yet to see if it meets our needs, but could do that once I have a better understanding of the mapping.
I think it is important to discuss two things next week: 1) Allowing mda on all extension points, 2) Clarifying why some modules are explicit and others aren’t,
e.g. to borrow Yves’ example, why isn’t res allowed in <group>? Would it be possible to have this discussion on Tues or Wed when Yves is present?
Ryan
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Dr. David Filip
Sent: Thursday, May 28, 2015 4:07 AM
To: Yves Savourel
Cc: XLIFF Main List
Subject: Re: [xliff] Extensibility in Core and Modules
@Yves, allowing mda on all extension points works for me
We can discuss explicitly prohibiting modules where they are not listed in the spec.
Will you be able to attend at least a part of the f2f online to resolve this?
I don't think it makes sense to continue the discussion of the intent, while we could continue arguing, it wouldn't really help solve the issue.
For Ryan's case, Ryan you could use the TBX namespace to extend the gls, the advantage would be that you would have 1-1 TBX mapping as gls and core (term annotation) map 1-1 to the compulsory subset of TBX Basic.
Although I think that you are OK to add mda on gls, this is not the TC consensus and mda can be explicitly allowed for 2.1 the soonest. Also TBX has the terminology business logic and is broadly supported by TB systems..
=======================
OASIS XLIFF TC Secretary, Editor, and Liaison Officer
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
On Tue, May 26, 2015 at 3:31 AM, Yves Savourel <ysavourel@enlaso.com> wrote:
Dear David, all,
> 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*.
The extension mechanism is defined as follow:
[[
XLIFF 2.0 offers two mechanisms for storing custom data in an XLIFF document:
- Using the Metadata module for storing custom data in elements defined by the official XLIFF specification.
- Using the standard XML namespace mechanism for storing data in elements or attributes defined in a custom XML Schema.
Both mechanisms can be used simultaneously.
]]
This is clear to me: Extensions can be carried by either Metadata (as a module, where defined) or by a custom namespace.
The namespaces of modules are not 'custom namespaces' (hopefully we agree on that), hence they cannot be extensions.
There no provision in the specification and no discussion the email archives (as far as I can tell) that show the TC ever intended to allow the modules to be used like extensions.
> Module namespaces reused at general extension points are simply
> not modules, even though their namespaces are XLIFF defined.
Modules are modules. If they are not listed in the specification they cannot be used at all.
A module is defined by the TC and has specific PRs, locations, relationship with the core, etc. An agent cannot re-purpose a whole module to mean something else. For example the <res:resourceData> element means something in <file> (where it is listed by the
specification), it cannot mean something else in <group> (where it is not listed, and according your interpretation, could be used as an 'extension'). It would be utterly confusing for the users and a mess for the implementer.
> Being XLIFF defined is a necessary but not a sufficient condition for
> something being a module.
What are the other conditions to be a module?
(And where do you see them defined in the specification?)
> 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.
Metadata is certainly meant to hold custom data, no question there.
But because it is a module it must follow the rules we have set for the modules: Not listed means not allowed there.
Ideally the specification would allow <mda:metadata> in every single extension point. I have nothing against that. It would make sense. But for some reasons, we do not have that situation for the modules. Somehow the TC ended up listing Metadata only in the
Matches module. Let's face it: that was a mistake.
But let's not try to correct that mistake by suddenly allowing modules to be treated like extensions.
That, by the way, would still not really solve Ryan's issue, because Metadata would still not be seen as Metadata by the tools supporting Metadata. So there is no real point trying to do that anyway.
> 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.
The specification a bit equivocal here because (after all that is why we have that discussion).
It's very easy to forget that the schema doesn't enforce all requirements so anything that complements the schema should be very clear. The fact that I started by answering "Sure you can use metadata as an extension" to Ryan until he noticed that the validation
didn't allow it, and the fact that you still say it is OK, shows me that the text of the specification need to be clearer (regardless which interpretation is correct).
> @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.
I may have missed something, but again, where in the specification (or in the email archives) is there any statement or discussion that a module can be an extension? The definition of the extension mechanism shows that such interpretation is incorrect.
We went to great lengths to express which module was allowed at which location, nothing more.
|