Re: further feedback on the XKMS schema changes

How about the following criterion:

     If a significant number of those filling in the interop
     matrix want a change, then we change & if not, not. The
     WG chairs decide what numbers are significant if the
     issue arises.

The only good reason to change namespace at this point is
if someone's deployed something using the current one
which will misbehave when faced with an implementation
behaving according to the PR version of the spec/schema.
If that happened my sympathies would be with the person
requesting the change. No-one's asked so far.

Our default is then not to change.

Stephen.

PS: This doesn't give control of the namespace to a closed
group since anyone is free to write code and contribute to
the interop matrix.

Jose Kahan wrote:

> I talked with other colleagues who worked on SOAP. They told me
> that they had actually changed their namespace several times before
> reaching CR.
> 
> What the WG needs to consider is if the changes that are done are
> substantive or not. Quoting the process document:
> 
> <quote>
> After gathering implementation experience, the Working Group MAY remove
> features from the technical report that were identified as being "at
> risk" and request that the Director Call for Review of a Proposed
> Recommendation. If the Working Group makes other substantive changes to
> the technical report, the Director MUST return it to the Working Group
> for further work.
> 
> A substantive change (whether deletion, inclusion, or
> other modification) is one where someone could reasonably expect that
> making the change would invalidate an individual's review or
> implementation experience. Other changes (e.g., clarifications, bug
> fixes, editorial repairs, and minor error corrections) are minor
> changes. A Working Group MUST document changes (both substantive and
> minor) between steps.
> 
> A technical report is returned to a Working Group for further work in
> either of the following situations:
> The Working Group makes substantive changes to the technical report at
> any time after a Last Call announcement and prior to Publication as a
> Recommendation, except when the changes involve the removal of features
> at risk identified in a Call for Implementations. In the case of
> substantive changes, the Working Group MUST republish the technical
> report as a Working Draft.
> 
> The Director requires the Working Group to address important issues
> raised during a review or as the result of implementation experience. In
> this case, Director MAY request that the Working Group republish the
> technical report as a Working Draft, even if the Working Group has not
> made substantive changes.
> 
> </quote>
> 
> For the record, we didn't declare any features at risk.
> 
> In order to consider if we have made substantive changes, we can
> use the following criteria as a guide:
> 
> 1. Are the changes just editorial or more subtle? 
> 
>    If the changes are more than editorial and the schema actually
>    changes, we may need to change the namespace.
> 
> 2. Will existing implementations break if the schema's namespace
>    is not changed? If an implementation doesn't follow
>    the schema changes, will it still be compatible or will it stop
>    being interoperable? Will there be a risk of ambiguity between
>    different implementations?
> 
> 3. Will the changes in the schema or spec modify past reviews or
>    implementations of the XKMS spec (the LC review to be specific)? 
>    Are there only changes that will remove implementation ambiguity, 
>    but not significant ones?
>    
>    If there are only slight changes, we don't need to go back to LC.
> 
> 4. Will the schema or spec changes be difficult to port to existing 
>    implementations?
>    
>    If the changes remove ambiguity and make things better, we don't need
>    to go back to LC. If the changes do change the way implementations
>    work and are hard to port, it will probably be better to do republish
>    the doc again as a WD (or whatever is tolerated. I'm not sure myself
>    what to do in this case).
> 
> 5. Will any features be removed?
> 
>    If yes, we'll have to go back to LC.
> 
> 5. Are the changes editorial or substantive? If substantive, we need to
>    go back to LC.
> 
> Following this criteria, the WG has to decide on whether to apply
> changes and whether to change the schema's namespace.
> 
> My colleagues told me we can change the URL that points to the namespace
> without having to publish a spec.
> 
> Hope this helps.
> 
> -jose
>

Received on Tuesday, 12 October 2004 14:06:56 UTC