Re: [xliff] Namespace in modules

["Dr. David Filip" <David.Filip@ul.ie>]

Rodolfo,

Note is not normative. Proper modules will require new 2.x increments.

Even if you are adding or removing just one module, you actually must change core specification, if only in a immaterial way. We specify in core where and in what order the modules can occur..

2.x increments will take time depending on their volume. We must not be afraid of publishing 2.x increments, we introduced modules to make this easier.

As P&L SC Chair i understand that public reviews and OASIS ballots will need to be organized repeatedly and am ready to take on the challenge :-)

Cheers

dF

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

mailto: david.filip@ul.ie

On Tue, Nov 6, 2012 at 10:05 PM, Rodolfo M. Raya <rmraya@maxprograms.com> wrote:

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



---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org