Right, Markus. I can see your point. You are correct that it should be possible to dynamically process a query template refereced by a view request.
But back to your original question, I still think it's fine to keep the known output models as part of the search capabilities. Unless a provider that wants to work with a specific set of output models for some reason doesn't want to offer the search operation, only the view operation. Can you see any reason for that?
So, maybe we should try to define how the view operation could be used in different scenarios:
TAPIRLite providers ----------------------------- (no support for the search operation) Providers must advertise the query templates that are supported. View requests must reference one of the supported query templates.
Intermediate TAPIR providers ------------------------------------------ (support search operation with "static" processing of output models) Providers don't need to advertise query templates (optional), but they do need to advertise the output models supported. View requests must reference a query template that makes use of one of the supported output models.
Full TAPIR providers ------------------------------ (support search operation with "dynamic" processing of output models) Providers don't need to advertise any query templates or output models (optional). View requests must reference a query template that makes use of any output model which references concepts that are mapped by the provider.
I think this picture shows one of the ways of setting up a TAPIR network based on the view operation. By defining one or more query templates, it should be possible to seamlessly interact with different types of TAPIR providers.
And since the idea of PyWrapper is to become full TAPIR provider, it actually doesn't need to worry about advertising supported query templates or output models.
Let me know if it all makes sense... -- Renato
On 18 Jul 2006 at 10:32, "Döring, Markus" wrote:
yes and no. sure you need a template for views. but do we force providers to register supported templates? If an implementation can handle dynamic models, it surely can handle "dynamic" templates. And even if a providers says I only understand those 4 models, all query templates based on those 4 models should be easy to be processed. So dynamic/static models are important for views as well, cause templates are based on them.
But if the intention of views was/is for TapirLite only, then registered lists of templates are needed and dynamic templates dont make too much sense. And searches and inventories without templates could always also be called through their respective GET versions as well. So yes, an implementation could process "dynamic" templates, but maybe we just dont need them.
Then again if providers need to configure supported templates, all installations would be different - unless the implementation can handle "dynamic" templates and just retrieves all available query templates for their supported models from a central service and registers them automatically for the provider.
-- Markus
-----Ursprüngliche Nachricht----- Von: pywrapper-devel-bounces@lists.sourceforge.net [mailto:pywrapper-devel-bounces@lists.sourceforge.net] Im Auftrag von Renato De Giovanni Gesendet: Montag, 17. Juli 2006 23:01 An: tdwg-tapir@lists.tdwg.org Cc: pywrapper-devel@lists.sourceforge.net Betreff: Re: [PyWrapper-devel] WG: tapir: capabilities
Hi,
If I remember well, the "view" operation was re-included in the protocol just to handle query templates, especifically for TapirLite providers. So if someone wants to query a provider using some external output model that should be dynamically parsed, then the "search" operation must be used instead (using either XML or simple GET request). View operations are really bound to query templates, and they are not allowed to specify "filter" or "partial" parameters. -- Renato
On 17 Jul 2006 at 21:26, "Döring, Markus" wrote:
I was just about to edit the schema and realizing that
output models
are only specified for searches. but what about views? they
use query
templates, yes. but only the ones listed in capabilities? we
should
have dynamic ones here as well I think. And they link back to static/dynamic models.
So should models maybe become a seperate section not tight to search/view operations? I am going to modify the schema
nevertheless
already to accomodate the changes below - ignoring views for
now.
Markus