RESTifying Procurement – The Media Type

In the examples throughout this series I am using (among others) the hypothetical media type application/procurement+xml. In this post I will start fleshing out its specification.

A central aspect of the RESTifying Procurement project is the use of the UBL document family. UBL actually encourages adopters to customize the documents to suit the needs of the interacting parties which usually means specializing upon the very flexible UBL documents types. There are also guidelines for evolving the document types to forward incompatible new types but I’ll rather stick with standard UBL.

UBL has not been build with hypermedia in mind and does not provide explicit linking facilities. In order to address that limitation I’ll define a special processing intent for <cbc:ID> elements, make use of HTTP Link headers and, where appropriate, use hypertext enabled media types such as application/atom+xml.

The hypothetical media type application/procurement+xml encompasses specialized versions of several UBL document types and associates with them a processing model as far as that is necessary to enable the associated business processes to be carried out by software components communicating via HTTP.

The current list of document types (which I will update when new types are added) is shown below. For every document type a value for a type parameter for the media type is provided to enable content negotiation based on the individual document types.

UBL Document type parameter value RelaxNG Schema Example
Catalogue catalogue Catalogue.rnc (xml)
Order order Order.rnc (xml)


Additional Processing Rules for the <cbc:ID> Element
The <cbc:ID> element is used throughout the UBL for identification. Various attributes can be used to identify the schema to which the identifier itself belongs. A common use of the element would be

 
<cbc:ID schemeURI="http://labs.nordsc.com/schemes/products">
  PARTS-7635223</cbc:ID>

Which means that the thing being identified has the identifier PARTS-7635223 and that this identifier is taken from the scheme (namespace) identified by http://labs.nordsc.com/schemes/products. This is similar to Atom’s <category> element that combines a scheme and a term attribute for the same purpose.

Unfortunately, the element does not directly provide for the use of URIs for identification, meaning that one cannot do something like this:

 
<cbc:ID href="http://labs.nordsc.com/repository/items/1234">
  1234</cbc:ID>

That is a strange situation (at least in Web context): UBL provides an element for identification but does not support the use of URIs as identifiers. To solve this, I decided to cheat a little and turn the <cbc:ID> element into a hyperlink.

The <cbc:ID> element provides an attribute named schemeDataURI that enables authors to reference a resource where the scheme data is available (the list of all identifiers and their description).

What if I defined the processing intention of application/procurement+xml to understand the concatenation of the schemeDataURI and the actual identifier to be a URI identifier for the thing identified by the given <cbc:ID> element? Yes, that would enable <cbc:ID> to turn into a hyperlink.

An element such as

 
<cbc:ID schemeURI="http://labs.nordsc.com/schemes/items/"
  schemeDataURI="http://labs.nordsc.com/service/items/">
  PARTS-7635223</cbc:ID>

can then be interpreted as a link referencing http://labs.nordsc.com/service/items/PARTS-7635223.

For now the specification of application/procurement+xml consists of the specialized Catalogue document type and the special processing rule for <cbc:ID> element.

I will update this posting as the media type grows.

3 Responses to “RESTifying Procurement – The Media Type”

  1. [...] RESTifying Procurement – The Media Type [...]

  2. [...] and runtime environment for the REST procurement sample application. (By Jan Algermissen) RESTifying Procurement – The Media Type – Description of the media type being used for the REST procurement sample. (By Jan [...]

  3. [...] first it is left to us to apply it to our application problems: transactions, procurement, dynamic clients and so [...]

Leave a Reply