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,

> OASIS has rules for namespaces:
> http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNaming.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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]