As Tilman said, my question was about the casing of value types (Text,
Integer etc) and in this case the `choice`.
I also saw the one with "closed" and "Closed" - did also not help with my
overall confusion :D (VeraPDF seems to ignore the casing because they claim
the PDF with the above XMP metadata as PDF/A-3 compliant)
Thanks Tim for the input regarding using jempbox. I had jempbox in before,
but didn't find such a convenient way to get the XMPMetadata like with the
DomXmpParser (but also didn't look hard tbh :D) and i also thought that
xmpbox is the successor of jempbox (because of the alignment in versions
with pdfbox).
I will try jempbox again.
Am Fr., 4. Apr. 2025 um 13:53 Uhr schrieb Tilman Hausherr <
thaush...@t-online.de>:
> Hi Peter,
>
> This one is not about the conformance levels, he has
> <pdfaProperty:valueType>closed *c*hoice of Text</pdfaProperty:valueType>
> in his zf schema definition (first posting), but we expect
> <pdfaProperty:valueType>closed *C*hoice of Text</pdfaProperty:valueType>
> and it's not even sure if we're correct there or should accept any case.
>
> Tilman
>
> On 04.04.2025 13:29, Peter Wyatt wrote:
> > Don't confuse the specification of the XMP serialization with the use of
> XMP as separately defined by the ISO standards such as PDF/A.
> >
> > The correct answer here is specified in the PDF/A (ISO 19005) standards
> (specifically ISO 19005-3:2012 for ZUGFeRD e-invoices).
> > ISO 19005-3:2012, Table 8 "PDF/A identification schema: defines
> pdfaid:conformance to be a "Closed Choice of Text" with values "A", "B" or
> "U" - so always uppercase for PDF/A XMP conformance levels.
> >
> > And, yes, the XMP Metadata value for PDF/A conformance levels is always
> uppercase yet the monikers used to identify PDF/A files (such as
> "PDF/A-3b") always use lowercase (as also stated in ISO 19005 standards, in
> Clause 4 Notation). This is a common point of confusion.
> >
> >
> >> -----Original Message-----
> >> From: Tim Allison<talli...@apache.org>
> >> Sent: Friday, 4 April 2025 9:30 PM
> >> To:users@pdfbox.apache.org
> >> Subject: Re: PDFA extension value type case sensitivity
> >>
> >> Not that Tilman needs it, but to support his point, we use JempBox in
> >> Apache Tika because it is much more relaxed.
> >>
> >> On Fri, Apr 4, 2025 at 5:55 AM Tilman Hausherr<thaush...@t-online.de>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> It gets weirder, I found the XMP specification, sometimes they write
> >>> "closed Choice", sometimes "Closed Choice".
> >>>
> >>> I could change it, but it's possible you'd get other problems with
> >>> xmpbox anyway. You can try Jempbox which is also from us, but has a
> >>> smaller API and is more relaxed (xmpbox was created mostly to verify
> >>> PDF/A files).
> >>>
> >>> Tilman
> >>>
> >>>
> >>>
> >>> On 04.04.2025 11:06, Peter Nowak wrote:
> >>>> Thanks for your quick reply.
> >>>>
> >>>> I feared that it has to be case sensitive 😅
> >>>> The PDF generation unfortunately is not in our hands, we just get the
> >>>> files delivered to us by customers.
> >>>>
> >>>> Then I need to do some custom xml parsing to get the
> >>>> /<zf:DocumentFileName>zugferd-invoice.xml</zf:DocumentFileName>
> >>>> /out and can't use xmpbox for it.
> >>>>
> >>>> Thanks for the clarification
> >>>>
> >>>> Best regards,
> >>>> Peter
> >>>>
> >>>> Am Fr., 4. Apr. 2025 um 09:33 Uhr schrieb Tilman Hausherr
> >>>> <thaush...@t-online.de>:
> >>>>
> >>>> On 04.04.2025 09:13, Peter Nowak wrote:
> >>>>> I did not find a concrete answer to it in the xmp specs.
> >>>>> Are the value types case sensitive? We received a ZugFERD pdf
> and i
> >>>>> tried to read the xmp metadata with xmpbox but it fails because
> of
> >>> an
> >>>>> unknown value type. The problem is the casing ("closed choice of
> >>>>> Text"), not the actual value. (xmpbox expects an upper case C in
> >>>>> choice)
> >>>> ChatGPT says it has to be case sensitive (I hope I asked the
> >>>> correct question):
> >>>>
> >>>> Tilman
> >>>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:users-unsubscr...@pdfbox.apache.org
> > For additional commands, e-mail:users-h...@pdfbox.apache.org
> >
>
--
Peter Nowak
peter.no...@ecosio.com
ecosio GmbH
Lange Gasse 30 | 1080 Vienna | Austria
Have you checked our status page <https://ecosio-status.com/> already?
<https://www.linkedin.com/company/ecosiohq/>
<https://www.instagram.com/ecosiohq/> <https://www.facebook.com/ecosioHQ/>
<https://twitter.com/ecosiohq>
<https://ecosio.com/en/webinars?utm_source=signature&utm_medium=email&utm_id=2025_webinars>
VAT number: ATU68241501, FN 405017p, Commercial Court Vienna
Managing Directors: Christoph Ebm, Philipp Liegl, Marco Zapletal
