OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xliff] Extensibility in Core and Modules

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]