[tdwg-tapir] RE: WG: tapir: capabilities
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
-----Original Message----- From: Javier privat Sent: Mon 7/17/2006 4:00 PM To: Döring, Markus Cc: Copp, Charles; Renato De Giovanni; pywrapper-devel@lists.sourceforge.net; tdwg-tapir@lists.tdwg.org Subject: Re: WG: tapir: capabilities
I suppose is fine yes... It is also easier to explain dynamic/static :)
Javi.
On 7/17/06, "Döring, Markus" m.doering@bgbm.org wrote:
Renato, I agree with your remarks. And I think we should stress the dynamic/static meaning more than the standard/custom one.
If everyone agrees I would opt for the dynamic/static terminology then and modify the capabilities section as renato has outlined?. Especially as we have been refering to dynamic models ever since.
-- Markus
-----Ursprüngliche Nachricht----- Von: Copp, Charles Gesendet: Montag, 17. Juli 2006 15:29 An: Renato De Giovanni Cc: Döring, Markus; Javier privat Betreff: Re: WG: tapir: capabilities
I think - standard/custom or static/dynamic is a choice of terms that either would suit depending on how you want to emphasise what they do.
standard - meaning it comes provided for you as part of the service you are contacting and custom means that it can be changed and the user declares it. static/dynamic emphasise what the service is doing in processing terms.
I think your Renato's comment on <structure> makes sense.
Charles
Hi,
I think I'm fine with any of the options. It could be "standard" if you all liked. The only detail is that a standardOutputModel doesn't necessarily come from an external library of standard models. It can also be something specifically tailored by the data provider for some reason.
By the way, I'm looking at the schema now and it seems to be possible to have a "customOutputModels" element with attribute "accepted=true" but with no schema structure capabilities specified - which is inconsistent.
I think that the "customOutputModels" section is more related to the ability to dynamically process any output model specified in requests. In contrast, the "predefinedOutputModels" is just a list of "static" output models that are understood by the provider, regardless of having the response schema structure processed dynamically or not.
So another possibility would be:
<staticOutputModels> ...list of outputModels... </staticOutputModels> <dynamicOutputModels> <structure>...</structure> <dynamicOutputModels>
In this case <structure> could become mandatory (minOccurs=1) and we could remove the attribute "accepted". Just another idea... -- Renato
On 17 Jul 2006 at 13:20, "Döring, Markus" wrote:
hi, a name for "predefined" model. charles suggests "standard" as oppoased to custom. I think that hits the nail on the head.
other suggestions so far:
- standard
- shared
- preconfigured
- known
- available
lets pick!
-- Markus
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
A little off topic, but it occurs to me that a great deal of work is still ongoing with TAPIR, which suggests to me that it may be warranted to re-state my request for a simple message type - a log request. This request would be the same as a search request, except that the caller doesn't need a response. Providers would use this type of request to log data usage if the data were retrieved from a cache elsewhere. I remember talking about this in Berlin, at which time there was supposed to be a feature freeze. Clearly we've gone beyond that, so I'm requesting it again.
On 7/17/06, Renato De Giovanni renato@cria.org.br wrote:
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
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
participants (3)
-
"Döring, Markus" -
John R. WIECZOREK -
Renato De Giovanni