W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2004

query parameter name clashes?

From: Kendall Clark <kendall@monkeyfist.com>
Date: Fri, 17 Dec 2004 12:19:25 -0500
To: public-rdf-dawg@w3.org
Message-ID: <20041217171925.GA5541@monkeyfist.com>

Les chiens,

While I don't think it's the best idea, hardcoding URIs (and query
parameter names) is the *easiest* thing we can do re: helping
clients/servers interop with regard to creating URIs. I'd prefer some
kind of generative schema or some kind of dynamic discovery, but I
guess that's for later on.

But there's another issue brought up by hardcoding, namely, query
parameter name clashes with existing or deployed toolkits, apps, or
services. (And yet another issue, IRIs and i18n, which seems like it's
not going to get brought up at all, but isn't going to go away.)

The query parameter names in the existing protocol draft ("query",
"query-uri", "query-lang", "graph") plus some others likely to be
coming ("distinct", "limit") are very general terms, likely to clash
with existing libraries, toolkits, apps, and services.

Should we be concerned about this? If so, should we take steps to make
clashes less likely?

There seem to be at least two choices:

1. prefix all these query parameter names with a string: "dawg-" or
   "sparql-". However, this alters or distorts the meanings of some of
   the parameters, so perhaps a less meaningful string like "s-" is
   better? String could be a pseudo NS local name, like: "sparql:" or
   "dawg:". Some examples,
   
   /qsp?dawg:query=...&dawg:graph=...&dawg:query-lang=...
   /qsp?sparql:query=...&sparql:graph=...&sparql:query-lang=...
   /qsp?sparql-query=...&sparql-graph=...&sparql-query-lang=...

2. steal/pervert the XPointer syntax for a sparql() namespace in URIs
   (not sure if there's a relevant difference here between URIs and
   URIRefs...?).

   /qsp?dawg(query=...&query-uri=...)
   
   and with a "safe clash":

   /qsp?dawg(query=...)&query=...

   This isn't real XPointer, since there are no other schemes (and
   this isn't really an XPointer scheme anyway, since it's not
   identifying resource parts)

   Also, I don't know if wrapping our query key-value pairs in "dawg("
   and ")" will break existing tools.

I think we need to do something here, or at least document that we've
thought as a WG about the implications of URI clashes and breaking
existing deployments.

Kendall Clark
-- 
Sometimes it's appropriate, even patriotic, to be ashamed
of your country. -- James Howard Kunstler
Received on Friday, 17 December 2004 17:20:59 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:21 GMT