Re: protocol draft available

> Question on section 3, definition of 'Query Results':
> I don't understand "Query and other operation results are
> to be distinguished from the response codes that the
> server may be required to return". I think this is due
> to my non-native English. Is this the same as
> "Query and other operation results can be
> distinguished using response codes that the server may return"?

No, I just meant to say that there are, for some operations, two
things that together make up "the response": first, the results of the
operation, and, seconed, some response code indicating some bit of
status.

I'll try to reword to make it more clear.

> Question on section 5, definition of LimitQueryResults.
> Isn't the interpretation of the positiveInteger value
> dependent on the type of query result to be returned
> from the server to the client? For example, given number 5
> the bindings XML representation may return 5 rows/tuples
> but RDF/XML representation may return 5 triples? I don't
> know if this dependency needs to be brought up here but
> I think it needs to be brought up somewhere.

This is a reasonable point, and I'll put it on the TODO list.

> Question on section 5 C, operation 4 makeGraph:
> The last sentence starting 'Finally, makeGraph ..."
> uses a query that returns bindings for variable a.
> Should the example be using a CONSTRUCT mechanism instead
> of SELECT in order to make it clear for the reader that
> the result of the query results is triples i.e. an RDF graph?

Yes. I cut and pasted from an earlier example instead of writing a
query specifically for that example. Good catch.

> Suggestion on section 7 i.e. HTTP binding:
> I think adding the abstract syntax example in the beginning of each
> HTTP binding example would make it easier for the reader
> to map previous sections to these examples.

I suspect others will *not* like that, but I think doing something
like this will help. I intend to write some explanatory text
introducing each example. I was in such a hurry to get something out
to the WG, I assumed that you all had no problems reading HTTP
directly. But, yes, that's not a proposal for final-form.

> Question on Spaqrl-Stream attribute in HTTP:
> I could not find example where this attribute has its
> value set to 'true'. I hope this example gets added.
> I would then welcome discussion whether HTTP should be
> using chunked encoding.

Ah, good. Andy's argued that we don't need sparql-stream because the
XML format gives us that already, for free, as it were.

We need more discussion about this, I think; or, put another way, if
this were a real WG draft, and I were the editor, I'd want more
feedback from WG members.

> Question on section 7, operation 4. makeGraph, 5. dropGraph and
> 6. addTriples:
> We at Profium have implemented support for partial
> adding and partial deletion of triples. If a client
> sends a graph G1 for e.g. adding to the server
> and server only stores a subset G2 of graph G1,
> it announces in the reply the contents of G2.
> The client can then calculate which triples did not
> get added or deleted.
> I would thus like to suggest these operations include
> the resulting (created or deleted) graph in the response.

Hmm, that's interesting. Will have to think about it some more. I'm
leaning right now toward the client just issuing another query if it
really cares.

> - makeGraph now suggests it provides a link to the resulting graph
> via Location: attribute.

Yes.

> - dropGraph now suggests there is some RDF in the response in
> the form of <rdf:RDF>...</rdf:RDF>. Maybe this is already
> what I am asking for.

That's unclear. Adding it to TODO.

> - addTriples now suggests also via
> <?xml version="1.0" encoding="utf-8"?> that some RDF
> is coming back. May this is also already what I am asking for.

I'm not sure *what* these should return. There's something to be said
for addTriples() returning the resulting graph in toto; but in some
cases that's unworkable if it's a really large graph, so I suspect the
best thing to do is to give the client some way of suggesting what it
wants back.

> Some typos on the way:
> - ittself
> - SPARL server
> - indpendent
> - section 5C, 6. addTriples: http://www.w3.org/1999/02/22-rdf-syntax-ns is missing hash (#) from the end
> http://example/3.rdf> missing < from the beginning

Thanks a lot, Janne. Given XML 2004 going on around the corner from
me, I may not be able to crank out another draft this week. But I'll
try.

Kendall Clark
-- 
Sometimes it's appropriate, even patriotic, to be ashamed
of your country. -- James Howard Kunstler

Received on Monday, 15 November 2004 18:24:18 UTC