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

[Yves Savourel <ysavourel@enlaso.com>]

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.

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.



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

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.

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.


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

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

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.

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.
Maybe Jirka would have some ideas on how to do this.



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