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

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

Thanks Yves, inline..

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 Fri, Nov 29, 2013 at 4:00 AM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi David, all,

> Adding any module will require a full
> OASIS process.

Obviously it always will. The issue is that currently it'll be a "full OASIS process" of the whole specification, a change of
version.

It doesn't have to be that way. In fact, it should not be that way.

We should not have to go from XLIFF 2.x to 2.y just because a new module has been added, modified or removed.

What would be the status of the module if the version was not changed? 

A software doesn't change version each time a new plugin is available. Not having to change the main part of the specification is
one of the main reasons to have modules.

Standard is not software 

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

Changing the version has a major impact: every single tool has to be updated: they cannot know if a change of version is only for a
change in modules or in the core, so they have to assume it's for the core and therefore check their support against the version of
the document.

We said that we do not want to touch core unless necessary, and we said we are not going to break core backwards compatibility in 2.x versions.

That does not mean e.g. that a widely used feature cannot graduate to core..

This is an example of a business decision that the TC makes, maybe strategic decisions is better than business 

And I'm not even talking about the consequences of changing version from the OASIS process view point: that will become an
"opportunity" for changing other things in the specification and to comment on the whole specification. Basically we'll be opening a
can of worms each time we add/change/remove a module.

This is not necessarily bad, if in 10 years time adding a module will require major core changes,it will be a signal that 3.0 is needed..  

Modules should be like plugins and stand on their own, not be intertwine with the core. And the version/specification/schema of
XLIFF core should change only when the core changes.

We say that modules are optional sets of features, we have chosen a schema language that is not very expressive.

If we are going for 1 we are rendering the schema useless for validation  

> It is totally independent of
> this schema issue solution.

Absolutely not: The solution selected for this issue (where to put modules vs extensions) can lead to different ways to deal with
modules change.

Yet it will not change the fact that new modules will require full OASIS process and new minor version of the spec.  

Solution 1) allows you to keep the core specification and schema unchanged while adding/changing/removing modules. That is true
modularity.

And it makes the schema useless in protecting modules in core only applications 

We can keep the PR distinction between modules and custom extensions being preserved or not by changing the PR to check on the start
of the namespace of the non-core elements. That will work without the tools having to know explicitly about the modules.

Your other issue has to do with validation.

First, you cannot truly validate a module with only the schema (you have PRs too). So whether or not the verification of the
location of the module's elements is done by schema or another mean is not really relevant.

We have chosen a schema language that is not very expressive,so we should not try to make it even less usable for validation by going for solutions like 1 

As for doing the validation.

NVDL (http://www.nvdl.org/) seems to exist exactly to do validation of documents using multi-namespaces. It's an ISO standard and it
allows the use of XML schemas. I'm no expert on this, but it seems one should be able to create high-level rules defining where
modules are allowed and trigger their schema validation.

We could do this, or rewrite the whole schema in RELAX NG,or many other fancy things if we did not care that the standard publication as result slips to 2015.. 

I do care,I hope that others do.. 

Maybe Jirka would have some ideas on how to do this.

Jirka would sure be able to do this, if he was on this committee.. but even Jirka would not manage to do this still in 2013.. 

> ... but at the same time stick

> to the business decisions that the TC resolved
> in the course of the standards development.

I don't know what "business decisions" means in a Technical Committee. I just know that one of the main requirements the TC decided
for 2.0 was modularity, and currently we have something that looks like modularity but is not really that in practice.

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

I don't share that opinion. The goal is the get a good specification. Achieving it for a given date is just gravy.

The community will stop waiting if we return to the drawing boards.

You requested to move modules from appendices to the main body (which was done) and now you request to move them to separate documents with separate approval process.

That would mean that both public reviews we made so far revealed that the spec is unfit to progress, we would need to go back to wd01 and have another initial 60 days review.

I do not share this opinion..   

I've never been fan of deadline-driven agenda in this TC because, while we have been lucky to have a few sponsored face-to-face
meetings, most of the work required is not funded. Imposing deadlines on busy people who don't get paid to met them simply doesn't
work.

If someone tells you they are not very happy with the speed of the TC, maybe you can suggest them to put their money where their
expectations are and pay for the time such work requires.


Regards,

-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