Jena's RDF/XML parser, ARP, was original a separate subsystem that could
be configured for different possible directions of the RDF 1.0 working
group and different treatment of IRIs that were possible at the time
(this is before RFC3986/3987). It is the "xmlinput" package in jena-core.
It has a close coupling to jena-iri with features such as customization
of errors, and an idiosyncratic approach to relative IRIs (if called
directly). These are outside normal use of RDF/XML. When used from
model.read or a RIOT API, these features aren't accessible.
Both jena-iri and ARP are hard to maintain.
xmlinput is the last part of Jena that uses jena-iri directly.
Jena has a IRI abstraction - IRIx that allows switching IRI providers.
The Jena releases use jena-iri as the provider through the IRIx
abstraction - errors message are the same as before.
There is a test suite for compatibility - on a pass/warning/error basis,
not error message text, that gives the expected behaviour of an IRIx
implementation.
RFCs and W3C documents that define the URIs, IRIs, and the specific URI
schemes evolve so maintenance is necessary.
RDF 1.1 removed the special "RDF URI reference" in favour of RFC 3987.
W3C has a REC about DIDs (a new "did:" URI scheme).
RFC 6874 changes the core URI grammar of RFC 3986, adding support for
IPv6 zones.
RFC 8089 define "file:" as it is actually used.
RFC 8141 replaces the definition of URNs with a new RFC.
My long-term aspiration is to have an RDF/XML parser and IRI handling
that is:
1/ Maintainable.
2/ For use as a parser in Jena and only for that.
That means making RDF/XML handling much simpler, with functionality for
reading conformant RDF/XML and not variations that are not used by Jena
users. The test suite has good coverage.
For IRIs, switch from jena-iri to a new IRI library that has up-to-date
support for IRIs. jena-iri also has scheme-specific rules for a large
number of legacy schemes (gopher:, telnet:, fax:, ...). This
extensibility causes a very high cost to maintain. It has not been
remade from the original configuration files for many years (that step
is not in the build).
New IRI library:
https://github.com/afs/x4ld/tree/main/iri4ld
jena-iri is also slower than iri4ld and this is visible in parsing (the
impact is 5-10% of parsing speed on N-triples.)
Error message do change, hopefully to ones that are easier to
understand. jena-iri error messages are quite technical.
This all applies to xmloutput as well but that's already converted to IRIx.
I have a new PR in-progress that converts RDF/XML parsing to use IRIx.
It does change the behaviour for directly using RDFXMLReader when
relative URIs are given as the base. A fully legacy setup exists that
passes all the tests for normal parsing use but does not pass some
detailed local behaviour tests in the RDF/XML writer.
Roadmap:
Eventually have multiple packages, until we decide that migration has
happened and they are getting in the way.
Packages used by RIOT/modle.read are essential maintenance only.
* xmlinput0 - this is ARP xmlinput as it is in Jena 4.7.0.
* xmlinput1 - this is ARP switched to use IRIx.
* xmlinput2 - an RDF/XML parser (starting with ARP and cutting out the
unused parts) that covers Jena needs and not trying to do everything ARP
does. xmlinput2 does not yet exist.
The new PR gets the codebase to xmlinput1(as "xmlinput").
If all goes well, we can have 4.8.0 default to use xmlinput1, switchable
back to xmlinput0.
When called from model.read or RIOT, it should not make a difference.
It would be great to have users test but any affected users are using
legacy features and they are less likely to upgrade regularly. Reports
about direct use of ARP have been very infrequent.
Andy
