[
https://issues.apache.org/jira/browse/JENA-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne updated JENA-675:
-------------------------------
Comment: was deleted
(was: 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.)
> 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)
