[
https://issues.apache.org/jira/browse/PDFBOX-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812514#comment-13812514
]
Tilman Hausherr commented on PDFBOX-1685:
-----------------------------------------
The build fails:
-------------------------------------------------------------------------------
Test set: org.apache.xmpbox.schema.XMPSchemaTest
-------------------------------------------------------------------------------
Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec <<<
FAILURE!
rdfAboutTest(org.apache.xmpbox.schema.XMPSchemaTest) Time elapsed: 0.007 sec
<<< FAILURE!
junit.framework.AssertionFailedError: Expected: <null> but was:
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertNull(Assert.java:233)
at junit.framework.Assert.assertNull(Assert.java:226)
at
org.apache.xmpbox.schema.XMPSchemaTest.rdfAboutTest(XMPSchemaTest.java:142)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172)
at
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:104)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70)
> Verify interpretation of rdf:about for PDF/A
> --------------------------------------------
>
> Key: PDFBOX-1685
> URL: https://issues.apache.org/jira/browse/PDFBOX-1685
> Project: PDFBox
> Issue Type: Task
> Components: Preflight
> Reporter: Maruan Sahyoun
> Priority: Minor
> Attachments: test-bfo.pdf
>
>
> There was a discussion about handling rdf:about for PDF/A validation on the
> PDF Associations mailing list which I'm allowed to share:
> <snip>
> In this case we have a PDF with an XMP metadata stream containing two
> <rdf:RDF> entries, one with rdf:about set to a blank string, the other with
> it set to a UUID. The PDF/A specification (ISO-19005-1:2005(E) para 6.7.2)
> simply says that the stream must conform to the "XMP specification 2004
> revision" which reads (p21):
> The rdf:about attribute on the rdf:Description element is a required
> attribute that identifies the resource whose metadata this XMP describes.
> The value of this attribute must follow URI syntax and may be either:
> ● an empty string (as in the example above), which means that the XMP is
> physically local to the resource being described. Applications must rely on
> knowledge of the file format to correctly associate the XMP with the
> resource.
> ● a unique instance ID that is generated every time a file is saved. The
> next section gives guidelines for creating instance IDs.
> The XMP packet must describe a single entity, and my reading of the above
> is a combination of empty-string and a unique UUID can meet this
> requirement - this is how both our software and Acrobat X and XI behave.
> However it's ambiguous, and this clause was revised in the 2012 revision
> (ISO 16684-1:2011(E) para 7.4) to this:
> If the XMP data model has an AboutURI (6.1, “XMP packets”), that same URI
> shall be the value of an rdf:about attribute in each top-level
> rdf:Description element. Otherwise, the rdf:about attributes for all top-
> level rdf:Description elements shall be present with an empty value. The
> rdf:about attribute shall not be used in more deeply nested rdf:Description
> elements.
> For compatibility with very early XMP usage, it is recommended that XMP
> readers tolerate a missing rdf:about attribute and treat it as present with
> an empty value. It is also recommended that XMP readers tolerate a mix of
> empty and non-empty rdf:about values, as long as all non-empty values are
> identical.
> Which means that an empty string and a unique UUID are technically
> incorrect, but it's recommended they be tolerated for compatibility
> purposes.
> </snip>
> I might be good to check our interpretation as
> <snip
> BFO and Acrobat X and XI think this is valid, PDFBox and
> pdf-tools.com online validator lean the other and classify this document
> as invalid.
> </snip>
> to see if we should change our interpretation. If there is new input on the
> pdfa.org mailinglist I'll capture it here too.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
