[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Namespace in modules
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]