Following on from the missing XMP Specification version number discussed in the previous post here below are listed some miscellaneous gripes I’ve got with XMP (on what otherwise is a very promising technology). I would be more than happy to be proved wrong on any of these points.
1. XMP version history and archive
There doesn’t appear to be any XMP version history or archive hosted by Adobe as far as I can tell.
2. Unpublished schemas
Also there is nothing published - outside the XMP Spec itself - on the core schemas used by XMP. There’s nothing to be gleaned from the namespace URIs used. The Adobe namespaces, e.g.
http://ns.adobe.com/xap/1.0/ (listed in XMP Spec)
http://ns.adobe.com/pdfx/1.3/ (not listed in XMP Spec)
seem to all resolve to this page
So, that can leave us with undocumented terms (e.g. ‘xmpMM:Manifest‘ used by Adobe InDesign CS2 4.0.5) from documented schemas and also undocumented schemas (e.g. ‘pdfx‘).
Note also that many Adobe apps do not use the URN syntax for ‘uuid:‘. The XMP Spec also has this to say:
_“There is no formal standard for URIs that are based on an abstract UUID. The following proposal may be relevant:
(see: 3 XMP Storage Model / Serializing XMP / rdf:Description elements / rdf:about attribute)”
I guess the XMP Spec (Sept. ’05) had just been bedded down more or less when the URN namespace for ‘uuid:‘ was published as RFC 4122 in July ’05.
4. RDF/XML serialization
XMP schemas specify fixed property value types in RDF/XML, i.e. they specify a fixed profile of RDF/XML instead of generic RDF/XML. This has been commented on recently by myself on the semantic-web list, and also here by Bruce D’Arcus speaking about OpenDocument, and here by Mike Linksvayer speaking for CC.
This profiling of RDF/XML leads to real problems. For example, Adobe have defined a Dublin Core (DC) schema which lists the property value types that DC values can assume in an XMP serialization. Meantime, the PRISM 2.0 draft spec defines an incompatible mapping of DC terms to XMP property values. Since both schemas would make use of the same DC namespace (though PRISM haven’t actually specified a DC namespace for use with XMP but do use elsewhere the regular DC namespace) this isn’t going to work. I did supply some feedback on this to the PRISM WG but have heard nothing back from them. So, PRISM XMP looks uncertain at this time. Which, for us, must be a shame.