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

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

Thanks, Yves, 

I was kind of surprised when Tom listed all the options again after the meeting where we had decided to go for 2)

Nevertheless, my bad, I should not have asked for dissent again, after I had outlined in response to Tom that 2) was the solution we agreed on in the meeting, I should have recalled the meeting consensus, but unfortunately the minutes had not yet been published at the point..

Nevertheless, as I see it, the dissent stands and this will need to be resolved by a ballot in the next meeting.

Now to react to your arguments:

Adding any module will require a full OASIS process. It is totally independent of this schema issue solution. Any module that won't be approved by the full OASIS process will not have the status of an official module.

The change to schema that will be required in case we go for 2, is add a new member (eventually to delete a member) in the single choice group at all three levels where the modules are allowed.This will have no impact on how the core works, except that there will be a different set of modules allowed in these choice groups.

The distinction between XLIFF 2.x and 2.y will always be how many module namespaces are allowed and hence absolutely protected in these choice groups, the working of the core will not change unless issues are identified that need to be fixed for the next version..

Finally, IMHO the TC will have failed if we do not kick off the 3rd public review before Xmas

Yes, I am trying to drive important changes to resolve technical issues, but at the same time stick to the business decisions that the TC resolved in the course of the standards development.

@Tom can you please prepare a spec version that implements option 2 for a live ballot in the next meeting?

In case the solution 2 will be rejected by the ballot, we won't be able to progress to csprd03.. and will need to discuss, find and implement another solution..

Cheers and Happy Thanksgiving..

dF

 

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 28, 2013 at 3:40 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

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



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