Namespace in modules

[Yves Savourel <ysavourel@enlaso.com>]

Hi all,

I had the action item to specify a proposal regarding the namespace in modules:

=== first, some background:

Currently the part of the draft defining a module says this:

"A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each official module defined for XLIFF 2.0 has its grammar defined in an independent XML Schema with a separate namespace."

Based on that:

-1 there is no restriction on what the namespace of the module is.
-2 It doesn't say you can use several namespaces, like we do with matches or glossary for example (where we use the XML and the core namespaces), so technically we could biker about the existing modules.
-3 it doesn't say any think about the version of the core and the modules
-4 it doesn't say anything about where modules could be set (so by default that could be anywhere).

The immediate concern I have is to make sure the ITS WG can map its metadata to XLIFF.
As it stands now, we cannot.

To be able to do it we would need either:

-A) That the <mrk> element allows extended attributes

-B) that we can for sure have a module allowing us to use ITS native markup in <mrk>

The solution A) is actually rather logical: <mrk> is where tools annotate the content, there is a limited mechanism in place that allows user-defined metadata to a certain extent, but it a bit like <metadata> for the element: it's not enough in several of our use cases.
The main problem with having extension at the segment level is about what to do with the data when re-segmenting. But in the case of <mrk> that problem does not occurs since it's an inline element.

But for various reason I think having a module instead is fine, and even probably better as it formalizes things a bit more.

So I want to make sure solution B) is doable. That in Dec-2013 when ITS 2.0 becomes a recommendation we can add a new module to XLIFF that simply uses the ITS native attributes.

The text we have currently is actually ok to achieve that, but as one could see this morning, that is not necessarily the opinion of everyone. So I want to make sure we have clear rules on how to add/remove modules in XLIFF.


=== A proposal:

So here is a possible text proposal for the section 1.1.3 entry "XLIFF Module". Maybe it should have a separate section, but that is not important:

A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process.

Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used. Modules can be placed in locations that are not extension points.

Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF, even if no other part of the specification has changed.

-- Either 1: A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC), from the World Wide Web Consortium (W3C), from the European Telecommunications Standards Institute (ETSI), from ISO, or from the Unicode Consortium.

-- Or 2: A module MUST only use namespaces of final specifications. The owners of these namespaces MAY be OASIS or other organizations.


=== and some comments on the proposal

- Adding a modules will require publishing a new version of XLIFF. Which is time consuming. I don't like that at all, but I don't see how otherwise make sure can modules evolve orderly. My concern is how much time will the TC take to add a new module.
This is also why I think both module and extensions have the same PRs for core-only tools: this allows time without preventing the extension-moving-to-modules to be impaired.

- I understand Fredrik's concern about not allowing "any" namespace as possibly used in extensions, but at the same time having a list is limitative: why only those organizations (whichever they end up being) have that privilege?
I'm really wondering if this restriction (the first option) is necessary: the TC is in charge of accepting or not the new modules, so it can refuse anything, including modules namespaces from those organizations.

What is important IMO is to state that one cannot refuse a namespace on the ground that only TC-defined namespaces are allowed. I've tried to capture this in the second option.


Regards,
-yves