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

[Yves Savourel <ysavourel@enlaso.com>]

Hi Tom, all,

Many thanks for layout the options.
I went through, trying to think about the pros/cons.


=== (1) Just have extension points in the core schema, treat modules and extensions the same from that viewpoint.

1-1) bad: You cannot validate where a given module is allowed using the schema (but you can still validate the module's element).
Allowed locations have to be defined by PR in the module specification.

1-2) bad but good: Core processors cannot make the distinction between module and extension: which means they have to preserve
everything (not so bad).

1-3) good: The core schema can stay the same when we add new modules. Modules can come and go without interfering with the core. It
seems to be a major benefit.

1-4) good: It keeps the main structure of a document always the same from 2.x to 2.z versions: optional stuff always goes after the
core parts at an expected location. 

1-5) good: Making an extension a module requires only changing the namespace.


=== (2) Would put the modules before the required <segment> in <unit> or or <unit>/<group> in <group>, etc.

2-1) bad: As Fredrik pointed out last call, now an extension that becomes a module has to move location, in addition to have its
namespace changed.

2-2) bad: Using methods like getFirstChild() to access the required core element of <unit> or <group> is no longer possible, you
have to skip over zero or more module elements.

2-3) good but bad: a core processor can now know which element is a module and which is an extension, and nuke the extensions (not
so good).


=== (3) Would add an element. I'll assume we choose to enclose the extensions not the modules.

3-1) bad: As Fredrik pointed out last call, now an extension that becomes a module has to move location, in addition to have its
namespace changed.

3-2) good but bad: a core processor can now know which element is a module and which is an extension, and nuke the extensions (not
so good).

3-3) good: It keeps the main structure of a document always the same from 2.x to 2.z versions: optional stuff always goes after the
core parts at an expected location.

My conclusion:

Solution (1) seems to be the best in my opinion. The only drawback is having to validate the position of modules' element using the
same tool that would validate their PRs.

My second choice would be solution (3): it has some of the same advantages as (1).

Cheers,
-yves