Thoughts on custom namespaces for extensions

[Yves Savourel <ysavourel@enlaso.com>]

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