Hi Tim,
If the provider only has a dump file and is not planning to offer any TAPIR operation in the future, I certainly agree there's nothing much to do with TAPIR. However, we all know that data harvesters may benefit if real TAPIR providers do offer some sort of dump file to help in the initial load. In this case, isn't it better to know from the capabilities response that the provider has a dump file in a certain format available in a certain place? If we don't include this information as part of a capabilities response, how would you know about it? I'm sure you'll prefer not to receive this additional information by e-mail from each provider...
Regarding TAPIRLite, the example you gave will only be technically correct if the service is also able to respond the 3 (currently) mandatory operations (metadata, capabilities and ping) and if the query template is defined according to the TAPIR spec.
Best Regards, -- Renato
Hi Renato, Markus, Kevin et al
Should a dump file really have anything to do with TAPIR? I would have expected to see it external to TAPIR spec - not to say that the wrapper software can't be a TAPIR wrapper plus a 'dump file' wrapper at the same time.
Similarly with TAPIRLite - maybe I don't get it right, or perhaps it was the early adopters, but one can be a TAPIRLite provider while only answering one search URL pointing at a custom query template with say a couple of GET params passed in, only support a custom response schema, yet claim TAPIR compliance - is this technically correct?
What say you guys? Looking forward to discussing with you all.
Cheers from Singapore Airport,
Tim