W3C home > Mailing lists > Public > public-sparql-dev@w3.org > July to September 2007

[Fwd: [whatwg] Comments on updated SQL API]

From: Dan Brickley <danbri@danbri.org>
Date: Sun, 23 Sep 2007 11:02:35 +0100
Message-ID: <46F639BB.8060904@danbri.org>
To: public-sparql-dev@w3.org

FYI, the What WG list (aka the shadow HTML WG <ducks/>) are looking into 
SQL APIs (for local storage, eg. Mozilla have SQLlite). Sort of like a 
super structured cookie system I guess.

Anyone care to prose a quad-store profile on top of it, plus SPARQL 
interface?

Dan

attached mail follows:



Mostly I like the new API (no surprise to Ian I'm sure).

http://www.whatwg.org/specs/web-apps/current-work/#sql

A few comments. I think putting the currentRow accessors directly on  
the ResultSet is a bit of an odd choice. It seems like it could be  
confusing that myResultSet[0] returns the value of the first field of  
the current row, rather than the first row. At the very least I think  
there should be a currentRow field pointing to a ResultRow object that  
has the accessors. Also, ResultRow could have item, namedItem and  
getName marked DontEnum to allow for..in to be used to get the field  
names, which is more idiomatic JavaScript than the getName method.

Another suggestion is that having a rows array might be more  
convenient than the combination of next(), validRow, and whatever  
accessors exist in the current row (either a separate object or the  
ResultSet could have array-like accessors). The tradeoff for the  
convenience is that you'd have to either cache any already visited  
rows in the ResultSet object (at minimum), since database cursors  
typically only offer iteration in one direction. This one is less  
obvious to me since iterating with next() is not all that inconvenient.

Regards,
Maciej
Received on Sunday, 23 September 2007 10:02:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:17:05 GMT