RE: [xliff] Namespace in modules

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

Hi Yves,

Adding attributes from ITS namespace is one thing and adding ITS native markup is quite different. I don't like the idea of elements defined outside the TC being treated as a module.

We cannot accept a module defined on a vague version of a standard. If you want to introduce a schema defined outside XLIFF, you must at least settle on a given version.

Converting a custom extension into a module does not require rewriting the XLIFF specification or changing the XLIFF version number. A module can be officially published as a Committee Note. Preparing a Committee Note should not take a long time, it would only depend on the writing speed of the person proposing the module.

Regards,
Rodolfo
--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms       http://www.maxprograms.com


> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf
> Of Yves Savourel
> Sent: Tuesday, November 06, 2012 7:36 PM
> To: xliff@lists.oasis-open.org
> Subject: [xliff] Namespace in modules
> 
> 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
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xliff-help@lists.oasis-open.org