ready to exit CR?

Andy Seaborne wrote

Maybe we could see where we are on the road to CR exit.


I am strongly opposed to exiting CR because of the issues
I have raised with the specification, which I regard as serious
and fatal.  In my view the purpose of a specification is to specify.
Examples do not constitute a normative specification. 
The document (both the CR and rq24) fails to specify in the following
important ways:

1. There is no bridge from the concrete syntax to the abstract
semantics.  Consequently the document can not actually be said
to specify the language at all, except that A.7 "Grammar" really
does specify the syntax.

2. The scope of blank node identifiers has not been stated clearly.
The consensus in an email thread appears to be that the scope
is a FilteredBasicGraphPattern (rule [21]) but the definitions in
2.5.1 "General framework" do not support this and need to be
rewritten.

3. The abstract semantics does not pay attention to the critical
issue of the domain of solutions.  Consequently the notion of
"solution" is not well-defined.

4. The preceding problems are perhaps at their worst in the
case of optional graph patterns.  The grammar does not indicate
what the first operand of a graph pattern is, and there is no
discursive text on the subject either.  Thus there is no bridge from
the syntax to the abstract semantics.  As for the abstract semantics,
the definition of OPT(A,B) appears to reduce to just solving A
with no role for B. 

5. It is not clear whether UNION requires an implementation to
count duplicate solutions precisely, which I personally advocate,
though I could live with the alternative of stating explicitly that
it is implementation-defined or -dependent how many duplicates
are returned.

Fred

Received on Monday, 31 July 2006 23:23:25 UTC