Subject: Re: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution)
Hi David, all,
Only the version of the added/modified module would change, not the version of the core or of the other modules.
>> 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?
Currently our single specification defines several namespaces:
urn:oasis:names:tc:xliff:document:2.0 (the core)
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:
because changing to this only:
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.
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
> 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.
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.
I don't have a good answer for validation.
> If we are going for 1 we are rendering the schema useless
> for validation
But I know going from 2.x to 2.y at each module change is not viable either.
If by protecting you mean respecting the PR that says modules MUST be preserved, I think I've addressed that with the suggestion of
>> 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
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..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
> I do care, I hope that others do..
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.
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
> The community will stop waiting if we return to the drawing boards.
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.
Yes. Tom's description of the options to solve comment #138 made me realize the specification is not ready to deal with new versions
> 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.
and modularity. That new problem has nothing to do with the other change.
Why deciding to split the main document would make us go back to wd01 for the core?
> 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.
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.
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: