OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Thanks Yves, I believe that we are making progress, I will comment below selectively.

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


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

I think that this would not be confusing at all, it would show people that the schema for core and a number of modules did not change since the last version. 

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.


This is only true if you buy into the argument that namespace URNs need to change even if the namespaces did not change. 

> 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.
The modules have been in appendices and they are now in their own section, they are optional still the TC decide to have them in one spec that fulfills a number of approved business requirements. Some of them are really small and I do not think it makes practical sense to separate them.   



>> 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.
I do not understand how this is supposed to work. the modules won't be explicitly included in our schema, so tool would be requested to know ad hoc about other namespaces that are not in the schema?

Would you say that stuff in namespaces starting with
"urn:oasis:names:tc:xliff:"

are OK to preserve? But we had a discussion saying that also w3c or similar namespaces would be OK, than we would need to anyway continue maintaining an exception list outside schema, I do not think this is practical.. 




> ... 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 guess if knew at the start what we know now, we could have considered a separate document approach and it might have worked, not sure, but might 

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.
I do not think that we have a bad specification. No specification is ideal.
I think we have modularity, certainly more of it than in 1.2 certainly less than ITS 2.0 but that would not be a fair comparison.
Our modularity in case of solution 2 would still be better than DITA specializations.



> 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.
We knew all the time that producing minor versions will mean producing an entire new specification.
I think that based on OASIS process we cannot possibly say that csprd02 has had lesser impact than csprd01 if we decided to drop all the module from the progressed spec, each of the modules would need to have its own progression. I do not know if anyone has bandwidth to do this, I certainly don't.

We've even discussed about a year ago that we do not want to bother with progressing every module individually.
This is just one of the consequences.
The options are either to accept it or to start a new progression with a new 60 day initial review.
The latter seems not acceptable to me.. 

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.
I think that this is true only if you accept that namespace URN have to be changed even if the schemas did not change. 



> 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.
I understand how those conflicting request arose, still I think that they are heavily interconnected. Having the modules in the main body as a section is even more inline with OASIS requirements, Martin mentioned that he was not particularly happy about the appendices but admitted that we might have good reasons not have the modules in the main body. 



> 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.
As I said above we would not sustain that we are progressing the same product. In fact a significant portion of features would be dropped.
If we decide for what you propose, I will certainly NOT try and argue that we are pushing the same product..  
So I sincerely hope that we don't and that you admit that the stakes are too high.

In my opinion the main issue is to find a solution for validation.
I think this is true and the solution 2 provides it simply through schema 1 that we decided to stick with for some good reasons, such as stability,wide adoption etc. even as we knew about its limited expressivity. 

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]