- From: Elliotte Harold <elharo@metalab.unc.edu>
- Date: Mon, 06 Mar 2006 09:47:16 -0500
- To: Dan Connolly <connolly@w3.org>
- CC: Pat Hayes <phayes@ihmc.us>, public-rdf-dawg-comments@w3.org
Dan Connolly wrote: > The number of reviewers, users, and implementors that we would need > to collaborate with in order to take ?var out is considerable, and > it's not clear that we have an argument that is sufficient to convince > them. True, allowing both adds various costs, but this is largely > sunk cost. The details of the specification are worked out; we have > test cases and multiple implementations. A growing number of users > have learned the ?var syntax, and those that need to use ODBC-style > systems seem to know about and be happy with $var. > It seems unlikely that we would get consensus around a change > to take out ?var or $var in a reasonable amount of time, and the > number of parties that are interested to see SPARQL advance to > Candidate Rec soon is considerable. > > > Again, please let us know whether you find this response satisfactory. > No. I don't. I'm reminded of the story of make. Very early on the inventor noticed that the syntax was basically completely wrong, and he needed to change it. However he wasn't allowed to because there were already dozens of people using this. Two means of identifying variables identical in every way except for the character used is just wrong. Removing one would simplify test suites, software, and documentation. It's some work, but it's work worth doing. The result would be a simpler, cleaner, more usable spec. Putting on my author/teacher hats and speaking as someone who writes and teaches a lot of tutorials about these sorts of things, every option one adds more than linearly increases the complexity and difficulty of grokking a technology. It's pointless duplication. There's no reason except inertia to keep it. It needs to go, and I don't think it's at all unreasonable to bring this up at last call. Any implementer who is starting before CR should be fully aware that the spec may change out from under them. As spec changes go, this is an easy one to adapt to. It just requires deleting code, not writing anything new. -- Elliotte Rusty Harold elharo@metalab.unc.edu XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
Received on Monday, 6 March 2006 14:47:24 UTC