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] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing requirements


Hi Yves,

As long as the XLIFF TC is not the one that maintains ITS, anything from ITS has to be considered a custom extension.

If you want to define a module that mimics ITS, that’s fine as we will be the ones in control. 

If you want to embed ITS in XLIFF, then the agreed restrictions for elements that allow custom extensions should apply. There should not be anything from ITS inside <segment>.

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 10:09 AM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing
> requirements
> 
> Hi,
> 
> > OASIS has rules for namespaces:
> > http://docs.oasis-
> open.org/specGuidelines/namingGuidelines/resourceNam
> > ing.html The namespaces we publish must be conformant.
> > We cannot publish a namespace from W3C as our own.
> 
> Thanks for pointing the documentation Rodolfo.
> 
> I see rules on how OASIS URIs and names in general should be done, but as
> far as I can tell there is nothing that says we cannot use attributes of a non-
> OASIS namespace in a specification. In this case we're not creating a new
> schema/namespace, we are defining a module that says how to use an
> existing standard.
> 
> 
> >> Any module will have to use
> >> a namespace defined by the XLIFF TC following the rules stated by
> >> OASIS.
> 
> If we were to define a new namespace we would have to follow the OASIS
> rules for its URI, but I didn't see anything in the document that states that
> modules must be defined through an OASIS namespace.
> 
> Even our own statement of what a module is says (section 1.1.3):
> 
> "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."
> 
> There is nothing there that says the namespace must be defined by the TC,
> or cannot be the namespace of an existing standard.
> 
> We can update the core schema exactly like for the Glossary or the Match
> modules by telling where the attributes/elements of the module are
> allowed. What the URI of the namespace is has no bearing on this.
> 
> Not using the ITS namespace would make the markup non-interoperable. It
> would also go against one of the take-aways that the TC got from it users at
> the first XLIFF symposium: re-use existing standards. We would be re-
> defining something that already exist and that could be used as-it.
> 
> 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]