So can we close this JIRA now?
The one take-away is the somewhat bigger issue of relative IRIs. Allow,
tolerate sometimes, or really go to lengths to discourage.
Andy
On 04/01/14 14:43, Claude Warren wrote:
I don't have any problem defaulting to RIOT readers, and I understand that
the setting of the reader factory is in the ModelCom init.
However the test cases for Graph had tests that looked for the exception to
be thrown, thus my thought that there was a contract that was not being
kept.
I will adjust the test case to ignore the case where the exception is
thrown and will see if I can narrow it down to checking for just the one we
expect to see.
Claude
On Sat, Jan 4, 2014 at 12:20 PM, Andy Seaborne (JIRA) <[email protected]>wrote:
[
https://issues.apache.org/jira/browse/JENA-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13862282#comment-13862282]
Andy Seaborne commented on JENA-618:
------------------------------------
Claude -
IO_JenaReaders.wireIntoJena is called during initialization implicitly.
If you put a breakpoint on IO_JenaReaders.wireIntoJena you'll see when
this is called (from ModelCom.<init>).
A different viewpoint is that IO_JenaReaders.resetJena() is an emergency
get-out in case the switch to RIOT was a problem so a workaround was
available while a maintenance release was done. It is no in a public API.
From the lack of user list messages, it looks like RIOT has not been a
problem.
I would much rather merge the codebases now and work forwards. We could
strip out the unused, out-of-date, and now not comformant, reader/writer
code as well (NT, TTL, N3).
We could have a discussion of the contract for relative URIs and also on
warnings and errors in parsing but point-by-point defect reports to extract
beliefs isn't very efficient.
(see the question "Why is it an ERROR when the code recovers and
continues?".)
The old world RDFReaderF design does not work very well because
# At odds with HTTP content negotiation.
# Does not address non-triples languages.
# The table of implementations is very hard to extend even for triples
languages.
# String names for languages get confused with base names in API calls.
# The flexibility to add custom readers per model is not used. It simply
is not something that has any meaning. (Maybe a possibility years ago but
the world has done a different way.)
For 1 - take a look at the operation {{model.read(url)}} in the core-only
world. It chooses the reader implementation (RDF/XML) then tries to open
the URL.
With RIOT, it makes the HTTP call, looks at the content-type (old world
does not use MIME types), then makes a decision on syntax by going to an
extensible registry.
calling IO_JenaReaders.wireIntoJena() and RDFReaderFImpl.reset() does
not reset the reader properly
---------------------------------------------------------------------------------------------------
Key: JENA-618
URL: https://issues.apache.org/jira/browse/JENA-618
Project: Apache Jena
Issue Type: Bug
Affects Versions: Jena 2.11.1
Reporter: Claude Warren
Priority: Minor
Attachments: test.java, test2.java
Calling IO_JenaReaders.wireIntoJena() and then RDFReaderFImpl.reset()
yeilds an RDF reader that does not fail when a relative URI is read.
It does report a warning if logging is enabled.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
