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

Re: protocol draft available

From: Kendall Clark <kendall@monkeyfist.com>
Date: Wed, 10 Nov 2004 08:19:16 -0500
To: DAWG public list <public-rdf-dawg@w3.org>
Message-ID: <20041110131916.GA25307@monkeyfist.com>

On Wed, Nov 10, 2004 at 03:38:45AM +0000, Steve Harris wrote:
> getOptions is not REQUIRED, from my experiences with Z39.50 I would say
> this is a mistake.

Well, I would mark all 7 methods required if it were up to me. :>

> Query example 1.1 seems to be a select that returns a section of an RDF
> graph (rather than a graph that describes a result set), I haven't URL
> decoded the string, but I dont see how that works.

Two things: I don't give any examples of XML variable binding sets,
simply because I couldn't find the msg in the archive that describes
the format. That's a wart that I intend to fix.

The key thing is the use of HTTP, not the payloads actually returned
(except in the case where I show returning an RDF graph to amplify the
meaning of an HTTP error response code).

Thanks for pointing this out. It's on the short list of things that
need to be fixed soon.

I thought seriously about *not* encoding the Request-URIs, since this
is a spec, not real network messages, and unencoded ones are easier to
read. Have to balance that against the possibility of misleading someone.

> Why do the HTTP binding arguments have []'s round them? I dont have a
> particular problem, with it, but it seems unneccesary, and a bit of a
> break from the norm.

Because of my argument, which is the first 5 paragraphs, surrounded by
"[[" and "]]", that I don't want to hardcode URI query parameters in
our specification. I'd prefer to either create/generate message
formats (basically, RDF graphs generated from WSDL 2 descriptions)
that can be dynamically discovered and which contain that information
or to create rules (like we did with HTTP and HTML forms) to generate

So, since I don't want to hardcode URI query parameters, but I need to
show HTTP messages, I chose a convention [PARAM_NAME] that I hoped
would signal that I wasn't suggesting that parameter name and was only
showing it because I wanted to show the other parts of some HTTP

Then I forgot to add it to my notation section, so it's no wonder
people are confused by it.

I'll fix that soon too. Eventually it can go away once we make some
decisions about hardcoding versus discovery versus generative. I
thought long and hard about this issue, talked to people about it, and
finally decided to punt it to the larger group, rather than continue
to delay the draft spec getting released.

Thanks for the comments, Steve.

Sometimes it's appropriate, even patriotic, to be ashamed
of your country. -- James Howard Kunstler
Received on Wednesday, 10 November 2004 13:19:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:45 UTC