[tdwg-tapir] Minor changes

[Renato De Giovanni]

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