RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution)

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

(sorry it's a bit long, but you should read it all).


> first of all in the meeting we had recorded consensus 
> that we go for 1) with modules forming a single 
> choice group at each point where they are allowed..
>
> This is also what I asked Tom to implement in the above.

I disagree. There was no consensus during the call, just a *possible* consensus and an action item for Tom to lay out the options so
people could confirm (or not) that option 2 would be ok. Why ask Tom to list the options if the consensus had been reached?

Tom follow-up, you answered and asked if there were any objections: "Unless people object, I'd like to ask you to regroup elements
in spec...".
My email (posted the same day as yours) was simply answering that.

David, I have nothing against trying to get things done as fast as possible; but I have to say that the number and scope of changes
we are introducing without much thinking is a bit scary.

Now this specific issue:

In this specific case: the issue of where modules and extensions go and can be distinguish is at the heart of a major aspect of 2.0:
modularity.

Option 1 has one major benefit: the core schema can stay the same when we add new modules. But you say that it is too high of a
cost.

Currently adding modules will require a new version of XLIFF, with all the burden of getting it approved by OASIS. That is one major
cost, and in my opinion it dwarfs not being able to validate the location of the modules with the core schema.

As we progressed through defining 2.0 it seems more and more clear to me that we truly need to separate the core from the modules.
In fact I think they should probably have different versions and even defined in different documents to make things clear.

Having a core that does not change and be able to modify modules distinctly from the core and other modules will be a very
significant advantage in the long term. It is actually the *main reason* of having modules.

By bundling everything into a single version and definition we are completely loosing that advantage: Every time any module is added
or modified the specification must be re-approved and all tools will have to adapt. It's time consuming and we will also end up with
tools supporting only some versions of XLIFF, and documents 2.z unable to go through multi-tools processes because of some module
that none of the tools are using has changed.

David: your main problem seems to have a requirement that module must be preserved while extension may not. Then maybe we can work
around this by changing the PR to have the tools distinguish between the two by looking at the *start* of the namespace URI of the
extension/module elements. This would allow both kinds to be mixed and keep the requirement intact.

I understand the wish for speed. But it should not lead to a bad specification.

Regards and Happy Thanksgiving.
-yves