The "PDF Declarations" specification lacks some clarity and is inconsistent in the use of trailing / and #:

• a correction was recently done for WTPDF declarations, changing from http://pdfa.org/declarations#wtpdf-reuse1.0 to http://pdfa.org/declarations/wtpdf#reuse1.0 - or should that be http://pdfa.org/declarations/wtpdf/#reuse1.0?

  • This issue is also to form a matter of record that this specific correction happened in the first place

• the example here has URI .../declarations#hippa but the PDF Declarations example on page 6 uses the URI .../declarations/#hipaa - these should be the same for consistency, but which one is "more correct"?

  • based on wording in XMP (see below) I'm guessing the more correct usage is always to include the / before the #, since the official PDF declarations namespace URI ends with a / and is thus this URI is then a simple concatenation.

• is there (or do we desire "should" or mandate "shall"?) a single correct way to specify URIs for declarations in the use of paths (/) or fragments (after #)? Should there always be a / before any #? Are there any recommendations for constructing well-designed PDF Declaration URIs (e.g. why was the original wtpdf declarations unsuitable? Why aren't WCAG 2.2 declarations also not done using a path?)

  • ISO 16684-1:2019 (XMP) clause 6.2. states: "Two XMP names shall be equivalent if their namespace URIs are identical and their local names are identical. This comparison shall be physical, byte-for-byte equality using the same Unicode encoding. Other processing, including but not limited to Unicode character normalizations, shall not be applied." and "A namespace URI used in XMP should end in a character that is not allowed in an XML NCName (the local name). Recommended characters are the slash ("/", U+002F) or the number sign ("#", U+0023). This can improve compatibility with applications that concatenate the namespace URI and local name, avoiding potential collisions." and further discussed in "B.3 Namespace URI termination"
  • it should not be assumed that every situation can call some URI normalization API e.g. the Acrobat custom XMP panels (https://pdfa.org/discovering-pdf-metadata/) are purely declarative so there needs to be consistency so precise string matching can be done