You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@taverna.apache.org by "Stian Soiland-Reyes (JIRA)" <ji...@apache.org> on 2018/01/11 15:55:00 UTC
[jira] [Comment Edited] (TAVERNA-1027) COMBINE parsing fails with
updated Jena - app URI scheme not supported
[ 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)