W3C home > Mailing lists > Public > www-archive@w3.org > September 2005

Re: Query forms should be resources, not operations

From: Mark Baker <distobj@acm.org>
Date: Mon, 5 Sep 2005 22:17:26 -0400
To: Kendall Clark <kendall@monkeyfist.com>
Cc: public-rdf-dawg-comments@w3.org, Dan Connolly <connolly@w3.org>, www-archive@w3.org
Message-ID: <20050906021726.GE17056@markbaker.ca>

On Mon, Sep 05, 2005 at 09:58:16PM -0400, Kendall Clark wrote:
> > I don't see that.  They may know which URL to POST to by discovering
> > descriptive information about that resource at the time they discover
> > the URL.  For example, they might learn about the URL via a triple like;
> > 
> > But they needn't even do that, since the application might just drive
> > them there, as would be the case with the use of XForms I described.
> Sure, that *may* happen, but it may not, too. In which case the reasonable
> client design (near as I can tell) is to sniff or parse the query itself to
> determine which kind of resource it should be routed to.

I still don't see it, because there won't be any standardization of URI
components, so the client wouldn't even know what to look for.  One
server developer may use "/ask" while another uses "/demander", while
yet another uses "/foo".  A client is just told to submit the query
(minus the form, as I previously described) to some URI and it does it
without any regard for the value of that URI.

In the case where the client explicitly wants to request that an "ask"
be done, only then would it need to be provided that information prior
to POSTing the query data.  One could imagine a SPARQL processor
supporting discovery of its services via some RDF that declares the
four resources and their types (ala RDF Forms via rf:Container type

> Again, speaking for myself, not DAWG here -- stay tuned for another DAWG
> response, I suspect.

Understood, thanks.

Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com
Received on Tuesday, 6 September 2005 02:15:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:32:45 UTC