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

Re: protocol draft available

From: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
Date: Thu, 11 Nov 2004 02:09:21 +0000
To: DAWG public list <public-rdf-dawg@w3.org>
Message-ID: <20041111020921.GI8296@login.ecs.soton.ac.uk>

On Wed, Nov 10, 2004 at 08:19:16 -0500, Kendall Clark wrote:
> 
> 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. :>

Well, does returning "permission denied" count as meeting the requirement
;)

I have some stores that are sifficiently large that doing the getGraph
opertation (or equivalent, dont have to document to hand) would be
ridiculous (gigabytes of data and some serious processing), so the only
sensible thing to do would be to refuse.

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

If you want my 2 pennorth, then showing the endoded form in the boxout,
with the ASCII version in the preamble would be the neighbourly thing to
do.
 
> > 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
> URIs.

Oops, sorry, I missed it, I did look for an explanation, but was a bit
short of time.
 
> 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.

OK, well, so far my vote is to hard-code it. Simpicity is worth a lot to
me.
 
> Thanks for the comments, Steve.

My pleaseure, more when I get a change to digest it properly. It reads
very well FWIW (modulo the bits youve marked for expansion). I would like
to see a <insert name of protocol> in a nutshell type thing though, for
people trying to write simple cients and the like, but nodoubt one will
get written sooner or later.

- Steve
Received on Thursday, 11 November 2004 02:09:23 GMT

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