Dear all,
I finished almost all changes both in the TAPIR schema and the specification, except for the new "dump file" capability. Next week there will be a meeting at GBIF, and since this is one of the things to be discussed, there will soon be another message here to finally make a decision. After this, I think TAPIR should be ready for standardization.
I've been also in contact with Markus, who's developing the new GBIF IPT provider. This will be the first implementation of a provider belonging to the category "Intermediate". For those who are unfamiliar with this, TAPIR providers can support different features, so at some point we decided to define 3 main categories of providers:
* TAPIR Lite: Providers that only support pre-defined query APIs (fixed set of parameters and output models); * TAPIR Intermediate: Providers that allow custom filters on a fixed set of output models; * TAPIR Full: Providers that allow fully customized responses.
The main reason for the Intermediate category was to remove the burden of parsing and interpreting output models and response structures. However, according to the specification, one of the parameters that TAPIR Intermediate providers need to support is the "partial" parameter. This parameter is used to point to one or more nodes in the response structure and force search responses to exclude all other nodes. This feature came from the BioCASe protocol to retrieve specific parts of huge schemas like ABCD.
The problem is that all mandatory nodes according to the output model need to be present in the response, even if they are not specified in the "partial" parameter. This way we avoid invalid XML, but this requires knowledge about the output model, which contradicts the original reason for creating the Intermediate category.
I can see two solutions for this: 1) Specify that the "partial" parameter only needs to be supported by TAPIR Full, which will make the parameter specification more intricate. 2) Remove the "partial" parameter from the protocol.
Since the protocol already allows different response structures to be defined and used, and BioCASe doesn't need to use the "partial" parameter anymore (to the best of my knowledge), I'm currently in favor of removing the parameter from the protocol to simplify things - unless this is being used by some other network (please let me know!).
Markus is also suggesting to remove the "omit-ns" parameter from the protocol. "omit-ns" is used to indicate that search responses should not include any namespaces at all. If this is not being used by any network or client, I also don't mind removing it.
TapirLink supports both "partial" and "omit-ns" parameters. If they get removed from the protocol I'll still keep them as unofficial parameters in any case.
Please let me know if you have any feelings about this.
Best Regards, -- Renato