Re: Query forms should be resources, not operations

On Mon, Aug 29, 2005 at 12:49:33PM -0400, Kendall Clark wrote:
> On Tue, Aug 02, 2005 at 05:11:43PM -0400, Mark Baker wrote:
> 
> > > I'm not entirely sure what the import of yr comment is. Can I ask for
> > > clarification?
> 
> [snip]
> 
> > > Is that what yr suggesting?
> > 
> > That's exactly right.  Nicely summarized.
> 
> Mark, I believe the design you suggest is more complex and more costly than
> the one we've presently decided on, and that it offers no appreciable
> advantages. At any rate, the WG believes it has considered a design similar
> to yours and made a different decision.
> 
> Unless there is some new information, I wonder if we could consider this
> issue closed?

Hi Kendall.

The group's position surprises me, as I would consider the approach I'm
suggesting simpler to implement as it should play nicer with existing
Web frameworks.  For example, rather than having to implement a separate
dispatching layer for the various "query forms", each would have a
separate URI, enabling the reuse of URI-based dispatching on a POST
request.

i.e. rather than this in Java;

public class SparqlProtocolServlet extends HttpServlet
{
  public void doPost()
  {
    queryForm = // ... parse out query form
    if ( queryForm.equals( "ASK" ) ) {
      dispatchToAskProcessor( args );
    } else if ( queryForm.equals( "SELECT" ) ) {
      dispatchToSelectProcessor( args );
    } else if ( queryForm.equals( "CONSTRUCT" ) ) {
      dispatchToConstructProcessor( args );
    } else if ( queryForm.equals( "DESCRIBE" ) ) {
      dispatchToDescribeProcessor( args );
    }
    ...
  }
}

you'd have;

public class AskServlet extends HttpServlet
{
  public void doPost()
  {
    // the code from dispatchToAskProcessor() goes here
  }
}

public class DescribeServlet extends HttpServlet
...

etc..

Much cleaner, IMO.

As for other advantages, my approach also avoids the security problems
of tunneling operations through HTTP POST.  More generally, it also
benefits from the "unintended consequences" of being more Web-like, by
identifying separate resources with their own URIs.  For example, one
might conceivably want to use an XForm to construct a SPARQL query, yet
XForms has no notion of SPARQL query forms, only the HTTP methods.
So the form need only have a URI to identify a specific instance of,
say, an ASK processor to which the document is directed.  As is, I
don't see how this would work in the POST case.  Even the GET case
would be convuluted, as the SPARQL query form would need to be
somehow specified within the form contents.

FWIW, I looked for the discussion around this issue to try and better
understand the group's concerns, but couldn't find any, just the
resolution to contact me;

http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/0243.html

Cheers,

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

Received on Monday, 5 September 2005 00:34:30 UTC