Re: better process for fixing problems in W3C recommendations

On Fri, 24 Jun 2016 01:31:29 +0200, Peter F. Patel-Schneider  
<pfpschneider@gmail.com> wrote:

> W3C recommendations have problems.  Unfortunately fixing these problems  
> is very problematic.  I suggest that W3C community groups be able, and
> encouraged, to submit reports pointing out problems in relevant W3C
> recommendations and providing errata for these problems.  These reports  
> would then be reviewed and, if approved, made into normative errata for
> the recommendation.

I don't think this is a process issue. This has been what the process  
outlined at least as far back as 1999, and I don't think it has changed  
meaningfully in that time.

There *are* practical problems.

1. Groups don't think in terms of errata. They are generally working on a  
new version, in which case the issues should be raised in the normal way,  
or not working on the spec, which means they don't do the necessary work  
of incorporating errata.

2. Groups that have closed can't work on a spec. Given the IPR framework  
in particular, substantive changes need a group to endorse a change.

3. While there are processes for filing errata, if nobody looks at them,  
they can disappear. Many old specs' process says something like "send  
email to [mailing list full of spam, with no subscribers]…". For new specs  
things are generally better, in that most new work uses github where it is  
*relatively* easy to file issues and track them.

> This process should be restricted to cases where there is a clear  
> problem in the recommendation, i.e., either there is some formal error,
> such as illegal structures being created or functions applied outside
> of their domain, or multiple implementations differ from the
> recommendation.

Those are the sort of bugs that need to be fixed, indeed.

> Part of the review process would be to ensure that there was adequate
> involvement of interested parties, particularly implementors of the
> recommendation and members of the working group that produced the
> recommendation.

That's actually already in the Process.

> Why is this a good time to establish this new process?  The W3C Data  
> Shapes working group is building SHACL on top of SPARQL.  Parts of
> SPARQL that it heavily uses have problems.  It would be much better
> if a resultant recommendation for SHACL could normatively depend on
> SPARQL as modified by the fixes that have been approved by W3C
> instead of saying that SHACL depends on SPARQL with some set of
> changes, which would in essence fork the definition of SPARQL within
> W3C.

This sounds like the standard rationale for starting work on a revised  
version of something actually.

> The RDF Tests Suite Curation Community Group would be a good group
> to handle errata for SPARQL, although it would also be possible to
> set up a new group specifically to address problems that are currently  
> known in the SPARQL recommendations.

Either of these would do. For the specific case, I'm just going to suggest  
you talk to the Team contact for SHACL about how to deal with this issue.  
I'll follow that up in any event, to see how good we are at acting on our  
existing process.

For the more general case, it probably is useful to spend some effort  
looking through the various mechanisms for filing errata on old specs, and  
ensuring they have at least been gathered and looked at by a person. I'll  
follow that up too - the AB is considering various aspects of maintenance,  
and this is a case that I think is pretty core to what should be happening.

If we standardised on github we could at least count opened untagged  
issues as a metric for whether we should be looking at doing some work on  
something. There are serious problems with using github for some of the  
community, but there are alternatives that have similar properties which  
we could consider.

Thanks for the prod. It's important to follow this stuff.

cheers

-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Sunday, 26 June 2016 11:41:58 UTC