Re: query parameter name clashes?

Kendall Clark wrote:
> 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.

The parameter names only mean anything in the context of a request to a SPARQL
query service.  Global names would be needed only if two services can be at the 
same service endpoint - I don't know of examples of that - anyone got any?

Having two independent service take a parameter "foo" doesn't matter until a
request for one service is sent to the other, which I consider unlikely, or 
where one service that take parameters from different service descriptions at 
the same service point is some kind of routing function (MVC is the only thing 
that might lead to that that I can think of right now but then the actions 
aren't independent but cooperating in a designed application).  But parameter 
name preservation isn't needed so it can use its own naming and export that as 
its service.

A more likely situation is that services live at different service endpoints so
the confusion can't arise.

  > (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.

Are there any examples of this occurring?

Aren't such libraries/toolkits (one with built-in parameter names) built to run
against particular services?

I'm not concerned until there is a concrete example of a problem because I don't
worry about requests meant for one service type being sent to another; I don't
see a need for a "universal" service either.

> 
> 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=...

':' might need to be encoded :-(

reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","

> 
> 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.

I think we need to quantify the issue first.

	Andy

> 
> Kendall Clark

Received on Friday, 17 December 2004 17:50:16 UTC