I tried to justify our design on this, but I couldn't
get Mr. Harold to accept our rationale.
Meanwhile, I don't see much new information. If anybody
else does, please let me know.
Otherwise, I'll add this to the list of outstanding dissent.
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Forwarded message 1
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