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


Reply via email to