Hi Christophe,
They would be good things to have.
XSLT processing done on the server is needed (the XML-world's vision of
XSLT client side doesn't seem to be universal enough).
For displayable forms do introduce a anothe rlevel of complexity
Maybe the right architecture is to regard the SPARQL database as the
data tier and have content produced in the business logic tier:
browser --> content engine --> SPARQL triple store.
The content phase for PDF etc is going to need a lot more control for
appearance, reacting to different clients. It's a part of a CMS solution.
This also suggests separate parallel development which could reduce any
roadblocks for you - there's no reason why in practcial terms you can't
embed Fuseki inside your own system and cut out the extra local network
hop - 3-tier can be 3-tier in architecture but not in deployment.
A separable bit would be to have a content engine as an extension to RIOT.
(Of course, you can, in theory, so it all in XSLT - no reason XLST has
to produce XML. But!)
See also the linked-data-api
http://code.google.com/p/linked-data-api/
and Epimorphics open source, unencumbered implementation:
http://code.google.com/p/elda/
This is taking the approach that turning general RDF into application
specific, and normal idioms, JSON, then processing as in any other web
app situation.
Andy
On 05/07/11 10:01, Camel Christophe wrote:
Hi everybody !
This message is particularly aimed at Jena/Fuseki developers team.
Fuseki offers the following formats for sparql results:
- WebContent.contentTypeResultsXML
- WebContent.contentTypeResultsJSON
- WebContent.contentTypeTextCSV,
- WebContent.contentTypeTextTSV,
- WebContent.contentTypeTextPlain
This is nice, but not sufficient for my needs (and the needs of my
company). I'd like to add new and popular output formats, like pdf, xls,
rtf and html (with xslt processing done on the server).
So I will very quickly begin development. Is the development team would be
interested in a contribution?
In any case, is it better to work on extensions directly in Fuseki or in RIOT
library ?
My concern is not to carry out development that would not be compatible with
future versions of Fuseki.
Thanks.
Christophe