RE: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing requirements

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

As we mentioned at the face-to-face meeting, the processing requirements for extensions certainly need to be worked on. The ones in the specification are, as you noted, just the initial proposal.

As for whether or not user agents should be able to delete extensions or not:

One major point to remember is that a custom extension ABC is not distinguishable from an official XLIFF module XYZ for the user agents that do not support that module. They both are just some elements/attributes in a unknown namespace.

You can see this from a different direction:
Forget about custom extensions. Think only about XLIFF modules from the viewpoint of tools supporting only the core.
We must have some processing expectations to preserve such modules.
This is what we need to define.
Then when it's done, we can just say the same apply to custom extensions because there is no logical reason to treat them differently.


> If someone wants to effectively use extensions for broader 
> interoperability as opposed to internal processing aid [which is 
> fully OK], they should seek to warrant their survival with other 
> means than a "carte blanche" from XLIFF TC.
>
> For instance, preserving ITS based extensions should be warranted 
> by the W3C recommendation (and its implementers) rather than the 
> OASIS stanadard and its implementers [the implmeneter groups can 
> obviously overlap].

I'm afraid that make no sense to me: XLIFF tools common behavior is driven by the processing requirements set in the XLIFF specification, not by anything else.
 
Let's say we have a custom element for some ITS data category, we try it out, etc.
Then 4 months later, we decided it works fine and it's stable and we'd like to make it an official XLIFF module.
We go through that process and the extension becomes an official module.

Why in the world a tool that supports only the core should have a different behavior before and after the extension become a module? For all we know at this point the element may even keep the same namespace. From the tool viewpoint, once again, there is no difference between a module it does not support and a custom extension.

So, I think we should stop thinking about the word "extension" and focus on getting the PR done. If it can help, think the extension is a "unsupported module". I'm going to use that term from now on :)

And with that in mind, I'd like very much the unsupported modules to be preserved whenever it's possible.

We may have PR related to how to behave with unsupported modules in specific places too. For example, it may be good to define what a tool do when removing an <mrk> element that has a ref attribute pointing to some element in the same unit. that element should probably be remove as well (assuming it's not used by another <mrk>). 

Cheers,
-yves