FW: SPARQL Query Results XML Format ready for review

Oops that was ugly. Trying again ...
Howard 

-----Original Message-----
From: Howard Katz [mailto:howardk@fatdog.com] 
Sent: Monday, July 25, 2005 10:27 PM
To: 'Dave Beckett'
Cc: 'public-rdf-dawg-request@w3.org'
Subject: RE: SPARQL Query Results XML Format ready for review

Dave,

I've walked through your XQuery code in
http://www.w3.org/2001/sw/DataAccess/rf1/result2-to-html.xq and have a few
comments.

(1) It seems odd to me to have a query that doesn't specify a target
document or input set in some fashion or other. I suspect you've been able
to associate your query with your example results-set document via some
out-of-band mechanism, such as the one provided by Saxon, but that type of
mechanism is implementation-dependent.

I'd suggest you set a top-level document-node variable that points to your
result-set document on the W3C site, as in:

     declare variable $results-doc := doc(
"http://www.w3.org/2001/sw/DataAccess/rf1/output.xml" );

If you do that and then root all the xpaths in the query at the above
document node, users will be able to see a direct reference to the document
being queried, and more importantly the query will actually work as is in
any XQuery environment. This would require changing this xpath, for example:

    <p>Ordered: { let $v := //res:results/@ordered return text { $v } } </p>

to this:

    <p>Ordered: { let $v := $results-doc//res:results/@ordered return text {
$v } } </p>

(2) While I'm looking at it, the above statement can be simplified a bit to

     <p>Ordered: { $results-doc//res:results/@ordered/string() } </p>

(The above use of string() is the "context-sensitive" variant; you can also
pass the entire expression into an fn:string() function, as in:

     <p>Ordered: { string( $results-doc//res:results/@ordered ) } </p> )

with the same results.

(3) This is much more in nit territory, but I'd recommend changing all
self-or-descendant operators (//) to child steps and actually specifying
each component in the path explicitly. In other words:

     <p>Ordered: { $results-doc//res:results/@ordered/string() } </p>

becomes this:

      <p>Ordered: { $results-doc/res:sparql/res:results/@ordered/string() }
</p>

This is both good pedagogy (the xpath recaps the actual structure of the
document), and most query engines (tho not my own!) will probably be more
efficient at resolving the path -- tho it hardly matters in this case, given
the small size of the document. As I said, nit territory.

(4) You can make your code conformant with the latest, April 2005 version of
the working draft by changing your existing variable declaration from this:

declare variable $variableNames {
   for $element in //res:sparql/res:head/res:variable
     return string($element/@name)
};

to this:

declare variable $variableNames :=
   for $element in //res:sparql/res:head/res:variable
     return string($element/@name)
;

(5) I don't know if this came from a prior version of the grammar, but your
namespace declaration at the top of the document:

       declare namespace default="http://www.w3.org/1999/xhtml";

isn't doing what I think you think it is. It should actually be changed to
this to conform to the latest version of the wd:

       declare default element namespace "http://www.w3.org/1999/xhtml";

Your declaration as given says that there's a namespace being used in the
query where the prefix "default:" is standing in for the url
"http://www.w3.org/1999/xhtml". That prefix of course isn't being used, so
this declaration is a no-op: The query works quite fine without it. (That
might be of course because there's already a
xmlns="http://www.w3.org/1999/xhtml" decarlation on the <html> element.)

(6) My only other nits concern some of the clauses in the if-then-else
structure that dispatches on the specific variable type.

This isn't incorrect:

	  if ($item/res:bnode) then
	     (: blank node value :)
	     text { "nodeID", string($item/res:bnode/text()) }

but you don't actually need the string() function on the final item, since
.../text() itself produces a string value. In other words,

	  if ($item/res:bnode) then
	     (: blank node value :)
	     text { "nodeID", $item/res:bnode/text() }

produces the same result, and even more commonly and concisely:

	  if ($item/res:bnode) then
	     (: blank node value :)
	     ( "nodeID ", $item/res:bnode/text() )    (: a sequence of two
string items; note the extra space in "nodeID ":)

and sometimes:

	  if ($item/res:bnode) then
	     (: blank node value :)
	   fn:concat( "nodeID ", $item/res:bnode/text() )

and finally, I believe the latter doesn't even need the final .../text()
dereference, since concat() itself causes each of its arguments to be
atomized, in this case to strings. So this would suffice:

	  if ($item/res:bnode) then
	     (: blank node value :)
	   fn:concat( "nodeID ", $item/res:bnode )

(Damn, those nits are getting itchy! :-)

Howard

 > -----Original Message-----
 > From: public-rdf-dawg-request@w3.org  >
[mailto:public-rdf-dawg-request@w3.org] On Behalf Of Dave Beckett  > Sent:
Thursday, July 21, 2005 6:56 AM  > To: RDF Data Access Working Group  >
Subject: SPARQL Query Results XML Format ready for review  >  >  > I've
updated the editor's draft to add both @ordered and  > @distinct attributes
to the <results> element.
 >
 > http://www.w3.org/2001/sw/DataAccess/rf1/
 > $Revision: 1.33 $ of $Date: 2005/07/21 13:51:05 $  >  > See  >
http://www.w3.org/2001/sw/DataAccess/rf1/#changes
 > for full changelog.
 >
 > Reviewers: I'd be interested on any suggested wordings about  > how to
record my confidence in the XML schemas.  See the  > words in red in section
4.
 >
 > There remain the usual publication todos: spellcheck,  > linkcheck,
pubrules.  As there are attached schema files  > refered to in the html,
xsd, rng, and so on they also need  > to be edited by the webmaster before
publication, i've left  > an @@FIXME@@ to remind about that.
 >
 > Dave
 >
 >

Received on Tuesday, 26 July 2005 15:20:10 UTC