I think undepending on Xerces is a good idea as well. With lots of other faster parsers to choose from it seems like we should not be forcing apps to include Xerces as well.
Claude On Tue, May 1, 2018 at 12:05 PM, Andy Seaborne <[email protected]> wrote: > FYI: > > Xerces 2.12.0 is out (as of April 21) though it has not made it to Maven > central. > > One thing of interest (to me) is whether it has a bugfixed version of > Duration. JENA-1402 > > I still think we should un-depend on Xerces. > > Andy > > > On 28/04/18 20:38, Andy Seaborne wrote: > >> JENA-1537 >> >> While the JDK does have a Xerces derived parser (it split off long before >> 2.11.0 and separately evolved), it is behind Java9 module "java.xml". >> >> Jena uses Xerces 2.11.0 in two ways - for the datatypes (oaj.datatypes) >> and XML parsing (oaj.rdfxml.xmlinput - also known as ARP). Both make >> internal use of Xerces. >> >> The datatypes uses Xerces provide XSD datatypes including validation. >> >> RDFXMLParser uses Xerces SAXParser and in a minor way some other stuff >> that isn't in java.xml.sax. >> >> I've had a prototype-hack go at removing Xerces from Jena: >> https://github.com/afs/jena-xerces >> >> Datatypes: >> >> * One feature omitted: XSDDatatype.loadUserDefined. >> >> These functions parse XSD scheme datatype definitions. The implementation >> calls into the internal XML parsing which would not be legal in Java9 >> modules if using the JDK built-in parser. It seems to need a fairly >> complete XML parser engine. >> >> We should consider dropping this feature. >> >> XML Parsing: >> >> * Looses the check on whether InputStreamReader or FileReader have the >> right encoding for the XML document. It hooks into an interface call that >> does not seem to be available in a standard SAX parser. (Shouldn't be using >> Readers anyway!) >> >> Andy >> > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
