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] Namespace in modules


Hi Rodolfo, all,

> 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.

Who said I wasn't?
Maybe you have missed part of the text proposal?

It says: "...A module MUST only use namespaces of final specifications..."
To me that is not "a vague version".

In the case of the module using ITS 2.0, I said we would present it when ITS 2.0 is a W3C Rec.
The minutes even recorded that (despite that they are pretty poor minutes):

Min> R: standard not finished yet
Min> F: but when stable, that's ok
Min> Y: will wait for when ITS 2.0 is stable, done.



> 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.

If we agree that a module can use attributes from a non-TC namespace (like xml:lang, or its:whatever) then what technical reason we would have to prevent a module to use elements from a non-TC namespace?

The TC is in charge of accepting the module or not. If the existing schema is not satisfactory (e.g. it an element that allows any elements itself) the TC can ask the submitter to fix his schema. The TC can make sure everything is under control as if it were defined by the TC, the only difference is it has a non-TC URI.

I don't want our XLIFF documents to be a mess either. I just want to make sure the specification explicitly state that modules can be made on non-TC namespaces. Something that is implicitly allowed today. If anything the proposal is more limitative that the current text.



> 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.

To add/remove a module, one has to change the schema of the core.
If we change the schema, we change the current version of XLIFF.
If we change the version of XLIFF, we have to re-publish.

Publishing a Note would make no difference: the core schema has to change.
I don't see how that can be done differently, but I may be missing something.
Maybe someone for OASIS could help us with this?

Regards,
-yves






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