Dear all,
Yesterday I finally managed to produce valid ABCD output from an instance of TapirLink that has mapped DarwinCore concepts. It could be possible to achieve this before by using a simplified XML Schema for ABCD, but I wanted to use the official one. The corresponding output model (inside our repository under cs/dwc/1.4/models) still needs to include more mappings between ABCD and DarwinCore elements, but it already works with the most important concepts.
One of the things that I needed to do was to create more environment variables to be used by output models, because there are mandatory elements in ABCD that don't correspond to any DarwinCore concept. However, they do correspond to TAPIR metadata elements.
The current TAPIR specification recognizes the following environment variables:
date timestamp dataSourceName accessPoint lastUpdated
I created these new ones in TapirLink, not only because of ABCD but also for the RSS2 output model:
dateCreated metadataLanguage dataSourceLanguage dataSourceDescription rights technicalContactName technicalContactEmail contentContactName contentContactEmail
If the specification doesn't include these variables, they will remain unofficial and this situation may not be good for future interoperability. So one of the things I would like to suggest is to include these variables in the controlled vocabulary defined by TAPIR.
Please let me know if this is OK and if you have more suggestions. (Markus, sometime ago there was the idea of including all TAPIR metadata as environment variables so that they could also be returned in search responses, would you like to suggest more variables?).
Remember that TAPIR environment variables are optional (providers don't need to support them) and extensible (providers can define new variables if they want to).
Here are two other minor changes suggested to the protocol and raised by issues that were found during the development of TAPIR tools for the GISIN network:
* Restrict POST requests to "application/x-www-form-urlencoded" (the default POST encoding). Reason: TAPIR requests can include multiple parameters with the same name ("concept" and "tagname" in the inventory operation) but some languages like PHP cannot handle this properly - only the last parameter becomes available from the $_REQUEST global variable. In these cases it is necessary to manually extract the parameters and this doesn't seem to be an easy task if POST is used with "multipart/form-data". Since this last encoding is mostly used for sending large quantities of binary data, which is definitely not the case of a TAPIR request, I think we can safely avoid it.
* Include an optional attribute "alias" in output models and query templates that are advertised in capabilities responses. The CNS configuration file already allows aliases for output models and query templates, but these are not present in capabilities responses as it happens with concept and schema aliases.
Please let me know if you have any comments, suggestions or objections to these changes, otherwise I'll take the liberty to make them in the next few days.
Best Regards, -- Renato