Hi Brian,
The tests for these area are
TestEscapeStr
AbstractTestPrefixMap
but the tests for PrefixMapAdapter aren't being run.
Jena itself does not use PrefixMapAdapter during Turtle writing. Writing
uses PrefixMap and, for performance and safety reasons, writing starts
by copying prefixes into a created via PrefixMapFactory.createForOutput.
We have invested time in that to get good performance for that
implementation.
Jena has several Turtle writers that may help you:
TurtleWriter
TurtleWriterBlocks
TurtleWriterFlat
https://jena.apache.org/documentation/io/rdf-output.html#formats
See also the request
https://issues.apache.org/jira/browse/JENA-2111
If you are updating an existing writer that works on PrefixMapping (as
did the old Turtle pretty writer forked by TopQuadrant), the newer
writers may help you.
Inline...
On 16/09/2021 06:12, Brian Vosburgh wrote:
Hello.
I am working on a custom RDF writer and encountered a few issues when
using some Jena classes. I wanted to check whether these are bugs or
as-designed.
Here are the issues:
- PrefixMapAdapter.abbrev(String uriStr) returns a Pair that simply
holds the two parts of the passed in uriStr, the URI and the local name. It
should be returning a Pair holding the appropriate prefix and the local
name.
- PrefixMapBase.abbreviate(String uriStr) has an extraneous call to
PrefixLib.abbreviate(PrefixMap prefixes, String uriStr).
Yes - these are issues
JIRA is at:
https://issues.apache.org/jira/projects/JENA/
- EscapeStr.stringEsc(AWriter out, String s, char quoteChar, boolean
singleLineString, CharSpace charSpace) does not escape a quote character
when it is the last character (and not the third of three consecutive
quotes) in a "multi-line" string that is being delimited with triple
quotes. The resulting delimited and escaped string will then end with 4 or
5 unescaped quotes. This causes problems when the string is read and
"unescaped" by a parser. That is, the resulting string will be missing its
final quote (or two quotes) and the dangling fourth quote (or fourth and
fifth quotes) will likely trigger a subsequent parse error.
- NodeFormatterTTL_MultiLine.formatLitLang(AWriter w, String lex, String
langTag) always delimits "single line" strings with double quotes;
unlike formatLitString(AWriter w, String lex), which will delimit strings
with single quotes if the string contains any double quotes (but not any
single quotes).
- NodeFormatterTTL_MultiLine.writeLiteralLongForm(AWriter w, String lex,
String datatypeURI) has the same problem.
Test cases for these would be appreciated so we fix teh deatils now and
in the future.
Andy
Are these bugs? Or am I misunderstanding?
Thanks!
Brian
