[Sparql4j-devel] RE: XML parsing

[Samppa S. <sam...@pr...>]

> There is a mismatch between the JDBC paradigm and the SAX paradigm.  
> JDBC is purely driven
> by the client application and there are no mandator call backs.  SAX 
> is driven by the rate
> of arrival as given by the parser so it migh have to accumulate 
> results until the client is
> ready.
>
> There could be a bounded pipe between application and SAX code but I 
> found it simpler to
> use a StAX parser (Woodstox) because the whole results-consuming 
> process is then determined
> by the application.  It is as easy to write StAX code as to write SAX > code.
 
StAX seems like a good choice.

> For handling SELECT queries, we don't need a full API.  We need to be > able to handle RDF
> terms, but not triples.

If we have a factory that can handle RDF terms, adding support for triples is trivial.

> For CONSTRUCT, etc, it might be better to properly link the result to > the local RDf toolkit
> of choice (e.g. via an InputStream).  c.f. SQL Blobs/Clobs.


I would find it more convenient to get the triples of the graph returned 
as triples (i.e. triple per row)
using the  factory along with speudo column accessors. This way we would 
(first of all) avoid special content-type handling. When using the 
InputStream-approach the user should be in control of the requested 
content-type. However, since InputStreams are more convenient in some 
situations (e.g. when using XSLT to process the results) maybe the best 
alternative would be to provice both... and since at least some of the 
use cases for InputStream access to the results are the same regardless 
of the type of the query, I see no reason to limit the usage of 
InputStream results only to construct and describe. To support these use 
cases we could overload Statement's execute with one that returns an 
InputStream. E.g.

Connection c = datasource.getConnection();

Statement select = c.createStatement();
InputStream results = select.executeRaw("<any sparql query>");


The preferred RDF serialization could be provided to the statement via 
select.setRdfLang("N3") similarily to other hints (e.g. fetch size, 
escape processing...).


Br,
  Samppa



-- 
Samppa Saarela <samppa.saarela at profium.com> Profium, Lars Sonckin 
kaari 12, 02600 Espoo, Finland Tel. +358 (0)9 855 98 000 Fax. +358 (0)9 
855 98 002 Mob. +358 (0)41 515 1412 Internet: http://www.profium.com