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] Thoughts on custom namespaces for extensions


Hi Yves,

A module is not the same as a custom namespace. A module is public and documented. Everybody would be able to implement support for official modules if desired. Modules are not a threat to interoperability, custom namespaces are.

Regards,
Rodolfo






Sent from my iPad

On Apr 17, 2012, at 7:04 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

> Hi all,
> 
> To follow up on the call's discussion about extension, here are two additional thoughts:
> 
> 
> === a) Using custom namespace willy-nilly:
> 
> Fredrik mentioned a drawback of using custom namespace for extension that I didn't noted before: The ease of use of custom namespace may tend to encourage people to create their own namespaces left and right without much consideration for interoperability.
> 
> That's a valid concern.
> 
> But maybe this could be address, at least to some level, in a better way than in 1.2.
> 
> We can have *conformance* rules regarding when and what types of extension one can have.
> 
> For example, the recommendation we had in 1.2: "...it is strongly recommended to use XLIFF capabilities whenever possible, rather than to create non-standard user-defined elements or attributes." should be set as a specific conformance rule:
> 
> - An extension MUST NOT implement an feature already represented in XLIFF.
> 
> Also, in addition to specify where extension points would be, we could also add specific conformance rules for restricting potential problems. For example:
> 
> - A custom namespace MUST NOT define a mandatory element that is directly the child of an XLIFF element.
> - A custom namespace MUST NOT define a mandatory attribute in an XLIFF element.
> - etc.
> 
> 
> === b) Custom namespaces and XLIFF modules
> 
> Another important aspect to this discussion is how exactly XLIFF optional modules are handled by tools not specifically implementing them.
> 
> I see that as important because in many aspects a custom namespace is a lot like an optional module.
> 
> It seems most of the expectations we would have for optional modules in general could apply to custom namespaces as well: whether a tool MAY/SHOULD preserve them, etc.
> 
> 
> Cheers,
> -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]