You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Andy Seaborne (JIRA)" <ji...@apache.org> on 2014/05/18 17:44:38 UTC

[jira] [Comment Edited] (JENA-675) Add and use a WriterProfile API

    [ https://issues.apache.org/jira/browse/JENA-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14001095#comment-14001095 ] 

Andy Seaborne edited comment on JENA-675 at 5/18/14 3:44 PM:
-------------------------------------------------------------

How much change is reasonable?  

The ideal design is to change {{WriterDatasetRIOT.write}} 

{noformat}
write(OutputStream out, DatasetGraph dataset, Context context) ;
{noformat}
and pass in the correct default {{OutputProfile}} for the language in the constructor. This can changed after construction before calling {{.write}}.  

An alternative is:
{noformat}
write(OutputStream out, DatasetGraph dataset, OutputProfile outputProfile, Context context) ;
{noformat}
but that moves the responsibility of a validly setup {{OutputProfile}} onto the caller.

{{ParserProfiles}} are not a complete analogous to {{OutputProfile}}.  {{ParserProfiles}} mutate state in prefix mappings and explicitly set base URIs; {{OutputProfile}} do not but do enlarge the {{NodeToLabel}} mappping.

The current operation is:
{noformat}
write(OutputStream out, DatasetGraph dataset, PrefixMap prefixMap, String baseURI, Context context) ;
{noformat}

(similar changes to {{WriterGraphRIOT}})

Given how new RIOT is, I'm minded to make the change, without compatibility. Leaving compatibility results in a decision down the line.  I don't know of other writers outside the RIOT codebase except RDF-Hadoop, and that's the main driver for the change anyway.


was (Author: andy.seaborne):
How much change is reasonable?  

The ideal design is to change {{WriterDatasetRIOT.write}} 

{noformat}
write(OutputStream out, DatasetGraph dataset, OutputProfile profile, Context context) ;
{noformat}
from
{noformat}
write(OutputStream out, DatasetGraph dataset, PrefixMap prefixMap, String baseURI, Context context) ;
{noformat}

(similar changes to {{WriterGraphRIOT}})

Given how new RIOT is, I'm minded to make the change, without compatibility. Leaving compatibility results in a desion down the line.  I don't know of other writers outside the RIOT codebase except RDF-Hadoop, and that's the main driver for the change now.

> Add and use a WriterProfile API
> -------------------------------
>
>                 Key: JENA-675
>                 URL: https://issues.apache.org/jira/browse/JENA-675
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: ARQ, RIOT
>    Affects Versions: Jena 2.11.1
>            Reporter: Rob Vesse
>            Assignee: Andy Seaborne
>
> Currently we have a {{ParserProfile}} which allows specifying certain aspects of input behaviour such as Prologue and Label to Node ID
> However we don't have a corresponding {{WriterProfile}} API, we actually have a class called {{OutputProfile}} but this is never actually used anywhere.
> This would be particularly useful for languages that rely on the {{NodeFormatter}} API where we can find comments such as the following:
> {quote}
> // Replace with a single "OutputPolicy"
> {quote}
> The lack of this API means we don't provide users any ability to do things like control how blank node IDs are allocated.  And existing functionality we do give them like providing a set of namespaces and base URI to use for serialisation needs to be folded into this API.
> I know of two places where this is currently causing issues:
> * In the incoming Hadoop RDF Tools code (JENA-666) many output formats currently mangle the data when outputting blank nodes because they can't share a {{NodeToLabel}} instance over multiple writer runs.
> * In an internal bug at Cray we're seeing a situation where different code paths lead to different presentation of blank nodes and we have no APIs to allow us to control this presentation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)