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 <> 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:
> For additional commands, e-mail:
>
