[ https://issues.apache.org/jira/browse/TAVERNA-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322442#comment-16322442 ]
Stian Soiland-Reyes edited comment on TAVERNA-1027 at 1/11/18 3:54 PM: ----------------------------------------------------------------------- I tested it separately in https://github.com/stain/jena-test-unregistered-iana This also tests file://hostname/path and http://hostname/path with the UUID as hostname, as RDF/XML, Turtle and NTriples - and testing with relative @base either inside the format or as parameter to Jena's RDFDataMgr. Modifying the Jena version its pom.xml yielded: * Jena 3.3.0, 3.4.0, 3.5.0, 3.6.0 exception in appRelRDF and appBaseRDF, wrong statements in fileRelRDF * Jena 3.0.1, 3.1.0, 3.2.0 wrong statements in fileRelRDF * Jena 3.0.0 no errors So only in RDF/XML is there an issue. For this Taverna bug it is appRelRDF that is relevant - so it worked until 3.3.0 - probably affected by Jena Changes in JENA-1306. I'll report this with Jena to check - I still think it should be valid according to: * https://www.w3.org/TR/2014/REC-rdf-syntax-grammar-20140225/ * https://www.w3.org/TR/2009/REC-xmlbase-20090128/ * https://www.ietf.org/rfc/rfc3986 So I don't think Jena should fail because of a non-IANA URI scheme - at least it is weird it only do so for RDF/XML. I've raised an issue in the [app-uri|https://github.com/sysapps/app-uri/issues/44] GitHub to see if app can be noted as a [historical scheme|https://tools.ietf.org/html/bcp35#section-5]. Perhaps for this particular parsing we can also use a [private URI scheme|https://tools.ietf.org/html/bcp35#section-6] like {{taverna.apache.org://}} instead of a fake {file:///} URI. (It's a separate issue that https://w3id.org/bundle/#absolute-uris now relies on a defunct URI scheme, but that's not Apache Taverna's spec, although that affects taverna-robundle) was (Author: stain): (Never mind the :: bit - that was never in the code :-) I tested it separately in https://github.com/stain/jena-test-unregistered-iana This also tests file://hostname/path and http://hostname/path with the UUID as hostname, as RDF/XML, Turtle and NTriples - and testing with relative @base either inside the format or as parameter to Jena's RDFDataMgr. Modifying the Jena version its pom.xml yielded: * Jena 3.3.0, 3.4.0, 3.5.0, 3.6.0 exception in appRelRDF and appBaseRDF, wrong statements in fileRelRDF * Jena 3.0.1, 3.1.0, 3.2.0 wrong statements in fileRelRDF * Jena 3.0.0 no errors So only in RDF/XML is there an issue. For this Taverna bug it is appRelRDF that is relevant - so it worked until 3.3.0 - probably affected by Jena Changes in JENA-1306. I'll report this with Jena to check - I still think it should be valid according to: * https://www.w3.org/TR/2014/REC-rdf-syntax-grammar-20140225/ * https://www.w3.org/TR/2009/REC-xmlbase-20090128/ * https://www.ietf.org/rfc/rfc3986 So I don't think Jena should fail because of a non-IANA URI scheme - at least it is weird it only do so for RDF/XML. I've raised an issue in the [app-uri|https://github.com/sysapps/app-uri/issues/44] GitHub to see if app can be noted as a [historical scheme|https://tools.ietf.org/html/bcp35#section-5]. Perhaps for this particular parsing we can also use a [private URI scheme|https://tools.ietf.org/html/bcp35#section-6] like {{taverna.apache.org://}} instead of a fake {file:///} URI. (It's a separate issue that https://w3id.org/bundle/#absolute-uris now relies on a defunct URI scheme, but that's not Apache Taverna's spec, although that affects taverna-robundle) > COMBINE parsing fails with updated Jena - app URI scheme not supported > ---------------------------------------------------------------------- > > Key: TAVERNA-1027 > URL: https://issues.apache.org/jira/browse/TAVERNA-1027 > Project: Apache Taverna > Issue Type: Bug > Components: Taverna Language > Affects Versions: language 0.16.0 > Reporter: Stian Soiland-Reyes > Assignee: Stian Soiland-Reyes > > I'm trying to update taverna-language to use Jena 3.6.0 (already updated in > taverna-maven-parent 3-incubating-SNAPSHOT), but then taverna-robundle fails > a test: > "Resolving against bad URI > <app:://4a8a0ff8-eab0-3930-8257-017dec3a8356/manifest0.xml>" > This seems to be because Jena's IRI support now fails for non-IANA URI > schemes like "app" when parsing RDF/XML - as within the COMBINE archive's > metadata. > In RO Bundle we use UUID-based [app: URL > scheme|https://www.w3.org/TR/app-uri/] as specified by W3C to represent files > within a Research Object zip archive. > That means naturally when parsing RDF files within that archive that we'll > use URIs like app://4a8a0ff8-eab0-3930-8257-017dec3a8356/manifest0.xml as a > base URI, so that a reference "fred.doc" becomes > "app://4a8a0ff8-eab0-3930-8257-017dec3a8356/fred.xml" > A workaround would be to replace "app" with "file", pretending the UUID is a > hostname, but somehow this also fails with Jena as it mangles > "file://4a8a0ff8-eab0-3930-8257-017dec3a8356/fred.xml" into > file:///4a8a0ff8-eab0-3930-8257-017dec3a8356/fred.xml after parsing - so it > becomes tricky tyo ask the RDF model about fred.xml afterwards. > A workaround to the workaround would be to use host-less file:/// URIs -- > another to drop the UUID and pretend file:/// is the root of the local file > system rather than the root of the zip archive. (This would also then > correctly support relative URIs like /fred.xml although those don't occur in > COMBINE archive) > Stack trace: > {code} > Jan 05, 2018 3:45:58 PM > org.apache.taverna.robundle.manifest.combine.CombineManifest findAnnotations > WARNING: Can't parse /manifest0.xml > org.apache.jena.riot.RiotException: [line: 3, col: 48] {E214} Resolving > against bad URI <app://4a8a0ff8-eab0-3930-8257-017dec3a8356/manifest0.xml>: > <./BorisEJB.xml> > at > org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.error(ErrorHandlerFactory.java:140) > at > org.apache.jena.riot.lang.ReaderRIOTRDFXML$ErrorHandlerBridge.error(ReaderRIOTRDFXML.java:254) > at > org.apache.jena.rdfxml.xmlinput.impl.ARPSaxErrorHandler.error(ARPSaxErrorHandler.java:37) > at > org.apache.jena.rdfxml.xmlinput.impl.XMLHandler.warning(XMLHandler.java:196) > at > org.apache.jena.rdfxml.xmlinput.impl.XMLHandler.warning(XMLHandler.java:173) > at > org.apache.jena.rdfxml.xmlinput.impl.XMLHandler.warning(XMLHandler.java:168) > at > org.apache.jena.rdfxml.xmlinput.impl.XMLBaselessContext.checkBaseUse(XMLBaselessContext.java:108) > at > org.apache.jena.rdfxml.xmlinput.impl.AbsXMLContext.resolveAsURI(AbsXMLContext.java:131) > at > org.apache.jena.rdfxml.xmlinput.impl.AbsXMLContext.resolveAsURI(AbsXMLContext.java:123) > at > org.apache.jena.rdfxml.xmlinput.impl.URIReference.resolve(URIReference.java:166) > at > org.apache.jena.rdfxml.xmlinput.states.WantDescription.startElement(WantDescription.java:63) > at > org.apache.jena.rdfxml.xmlinput.impl.XMLHandler.startElement(XMLHandler.java:111) > at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown > Source) > at org.apache.xerces.impl.XMLNamespaceBinder.handleStartElement(Unknown > Source) > at org.apache.xerces.impl.XMLNamespaceBinder.startElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) > at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at > org.apache.jena.rdfxml.xmlinput.impl.RDFXMLParser.parse(RDFXMLParser.java:150) > at org.apache.jena.rdfxml.xmlinput.ARP.load(ARP.java:118) > at > org.apache.jena.riot.lang.ReaderRIOTRDFXML.parse(ReaderRIOTRDFXML.java:135) > at > org.apache.jena.riot.lang.ReaderRIOTRDFXML.read(ReaderRIOTRDFXML.java:79) > at org.apache.jena.riot.RDFParser.read(RDFParser.java:334) > at org.apache.jena.riot.RDFParser.parseNotUri(RDFParser.java:324) > at org.apache.jena.riot.RDFParser.parse(RDFParser.java:273) > at > org.apache.jena.riot.RDFParserBuilder.parse(RDFParserBuilder.java:498) > at > org.apache.jena.riot.RDFDataMgr.parseFromInputStream(RDFDataMgr.java:870) > at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:268) > at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:254) > at > org.apache.taverna.robundle.manifest.combine.CombineManifest.parseRDF(CombineManifest.java:240) > at > org.apache.taverna.robundle.manifest.combine.CombineManifest.findAnnotations(CombineManifest.java:332) > at > org.apache.taverna.robundle.manifest.combine.CombineManifest.readCombineArchive(CombineManifest.java:465) > at > org.apache.taverna.robundle.Bundle.readOrPopulateManifest(Bundle.java:121) > at org.apache.taverna.robundle.Bundle.getManifest(Bundle.java:87) > at org.apache.taverna.robundle.Bundle.close(Bundle.java:61) > at org.apache.taverna.robundle.Bundle.close(Bundle.java:52) > at > org.apache.taverna.robundle.manifest.combine.TestCombineManifest.convertDirectoryMadnessZipped(TestCombineManifest.java:152) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)