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

["Dr. David Filip" <David.Filip@ul.ie>]

Hi Yves, Tom, Fredrik,

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 think everyone clearly sees that there is no ideal solution and we probably will need to decide with a ballot if this dissent is sustained following the consensus reached in the meeting..

Let me comment inline on the pros and cons summed up by Yves..

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

http://www.cngl.ie/profile/?i=452

mailto: david.filip@ul.ie

On Thu, Nov 21, 2013 at 8:23 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

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).

This is a no go in my view 

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).

This is a no go in my view. The TC decided by a ballot that extension cannot and must not be granted the same level of protection as XLIFF defined modules.  

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.

I agree that this is a benefit but the cost is too high IMHO 

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.

Same as above, I don't think it actually is a separate benefit 

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

I agree that this is a benefit but the cost (1-1 and 1-2) is too high IMHO 

=== (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.

This seems acceptable, you will clearly see which extensions have graduated to official modules and enjoy full protection, worth the move IMHO 

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.

You are skipping a single choice group of optional 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).

The TC agreed that schema should allow to discern between TC sanctioned modules that have absolute protection and wild card extensions that can contain ANYTHING and might need to get nuked for absolutely valid reasons 

=== (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.

This seems acceptable, you will clearly see which extensions have graduated to official modules and enjoy full protection, worth the move IMHO 

 

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).

The TC agreed that schema should allow to discern between TC sanctioned modules that have absolute protection and wild card extensions that can contain ANYTHING and might need to get nuked for absolutely valid reasons 

 

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.

Good, cost not too high.. just ugly 

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.

The drawback constitutes a no go IMHO 

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

Cheers,
-yves


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php