Hi Tim,
OK, now I think I can see from your point of view. You're considering a multi-protocol wrapper software on top of the same database, and it's strange to see the dump file being advertised by one of the protocols when it could be useful to any client. From a registry perspective, assuming that non-TAPIR protocols are unlikely to ever give an indication about dump files, this means that besides advertising all endpoints (each protocol with a separate endpoint, I suppose) you will also want to register the dump file as a separate link. A new service binding as you said.
Anyway, regardless the protocol being used by the client it also seems strange to use a specific protocol to interact with the provider but get the information about dump files somewhere else. Since we have the chance to still make adjustments in TAPIR, why not make things easier and more consistent at least for TAPIR clients? If we do this, the multi protocol wrapper could easily advertise the dump file twice: as an independent link (if you wish) and as part of TAPIR capabilities.
Regarding the TapirLite example, it's not exactly a misuse, but it's certainly good practice to periodically check the provider capabilities. In your case, given any TAPIR endpoint, a generic TAPIR client should ideally send a capabilities request first. If the two query templates are supported, you can proceed to the search requests. If not, you can still check if the provider supports the necessary output models. If they are supported, you can proceed to the search requests. If not, you can still check if the provider supports any output model and if the necessary concepts are mapped. If the answer is yes, you can send exactly the same search requests. If not, then the provider won't understand your search requests. This would be the way to cover the 3 TAPIR profile levels. The logic requires some understanding about TAPIR, but it's not complex. However, it definitely helps if you use a generic TAPIR client library to parse the capabilities for you and offer a few methods to return what you need.
Best Regards, -- Renato
Hi Renato,
Hmmm... I get what you are saying but would the wrapper tool be better to just register the existence of the dump file (or the meta file describing the dump) in a registry? E.g. A new service binding for a UDDI registration. If I bundled WFS with a TAPIR implementation I wouldn't advertise the existence of that in the capabilities, or would I? I foresee wrapper tools with WFS, WMS, TAPIR, locally generated index files (so called dumps), OAI-PMH, TCS complete dataset files, EML in a single installation - would the capabilities be flexible enough to allow for these additional protocols?
TAPIRLite - I think then to write a client you would have to be able to understand the templated request (E.g. deconstruct the filters) and work out the parameters required in order to construct the URL. To me it seems backwards since it is the provider saying to the client "this is the one query I support" which is more like just advertising a custom webservice - no? We must be misusing it, or shying away from writing complex client code at GBIFS as we only support 2 templates, which effectively says we only support 2 URL types and one output document format. So we don't even issue capabilities requests to these providers since they are known to be coded against the template... misuse?
Really looking forward to picking your brains Renato!
Cheers
Tim