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

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,


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

Only the version of the added/modified module would change, not the version of the core or of the other modules.

Currently our single specification defines several namespaces:

urn:oasis:names:tc:xliff:document:2.0 (the core)
urn:oasis:names:tc:xliff:matches:2.0
urn:oasis:names:tc:xliff:glossary:2.0
...

If something changes just in the Matches module, according to the current system the new version of the specification will have to
go to 2.1. Which means the namespace URIs would then be:

urn:oasis:names:tc:xliff:document:2.1
urn:oasis:names:tc:xliff:matches:2.1
urn:oasis:names:tc:xliff:glossary:2.1

because changing to this only:

urn:oasis:names:tc:xliff:document:2.0
urn:oasis:names:tc:xliff:matches:2.1
urn:oasis:names:tc:xliff:glossary:2.0

would be completely confusing for a specification labeled 2.1.

So, only the Matches module would change but we would have to change all URIs (and therefore all tools).
I don't think it make sense and it is certainly not modularity.



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

As shown above you don't need to break backward compatibility or even change a single thing in all modules but one to have the tools
incapable of working with the new version, even if the changed module is not even present in the document: You just need to change
the version of the specification.



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

I don't have a good answer for validation.

But I know going from 2.x to 2.y at each module change is not viable either.



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

If by protecting you mean respecting the PR that says modules MUST be preserved, I think I've addressed that with the suggestion of
changing the PR to preserve the elements based on the start of the namespace URI.




> ... if we did not care that the standard publication 
> as result slips to 2015..
> I do care, I hope that others do.. 

David, it's precisely because I do care about the success of 2.0 that I'm making all those comments. Releasing next month a 2.0
version that is not truly modular will help no-one.

I'm sorry those comments come so late and take me so much time to handle, but the alternative of saying nothing would be worst: a
bad 2.0 specification.



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

In my opinion it's not going back to the drawing board: We just have an issue on how to change the modules without affecting the
whole specification.

I don't think the community would like it very much when they realize all tools have to be changed each time a module is added,
removed or modified.



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

Yes. Tom's description of the options to solve comment #138 made me realize the specification is not ready to deal with new versions
and modularity. That new problem has nothing to do with the other change.



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

Why deciding to split the main document would make us go back to wd01 for the core?
We would just act to fix an issue: we have a single spec defining 9 namespaces and we would decide to have one spec per module.

In my opinion the main issue is to find a solution for validation.

Regards,
-yves