Thanks for the response, Andy. I will see what I can do about some Jira tickets and PRs in the near future.
Brian On Thu, Sep 16, 2021 at 4:55 PM Andy Seaborne <[email protected]> wrote: > 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 > > >
