Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir: capabilities

[Javier de la T. <ja...@mn...>]

I am not sure about this,

I still think that portals should be gathering this data and making =20
it available for data providers...

But in any case if you like it then I agree with MArkus that the best =20=

is to include another parameter in the operationRequestGroup.

I havent checked but what happens if you do an extension there with =20
an attribute that is implementation specific? A qualified attribute. =20
Will this still validate against our schema? You were discussing =20
about qualification of attributes before no?

Javi.

On 18/07/2006, at 10:41, D=F6ring, Markus wrote:

> John,
> all changes going on with TAPIR right now are really only changes =20
> in terminology or removing inconsistencies we did not detect before =20=

> we started the documentation and final implementation.
>
>
> But nevertheless I would support your request. Especially from the =20
> implementation side of view this is a trivial change to the code. =20
> So why dont add it? Just some additional thoughts:
>
>
> - Ive added a "simulation" mode already to my code where no SQL =20
> gets executed but just logged. So you can test configurations =20
> without risking sending off killer statements. Thats similar to =20
> logOnly I guess, returning nothing but diagnostics. What would you =20
> suggest to be returned for a logOnly request? just the empty TAPIR =20
> envelope? Nothing? <OK>?
>
> - would this log-only request not be needed for all requests? at =20
> least for inventories? So it would be easiest to have a new logOnly =20=

> parameter in the header or "request element" just after the header? =20=

> something like <search logOnly=3D"true">
>
>
>
> -- Markus
>
>
>> -----Urspr=FCngliche Nachricht-----
>> Von: pyw...@li...
>> [mailto:pyw...@li...] Im
>> Auftrag von John R. WIECZOREK
>> Gesendet: Montag, 17. Juli 2006 23:30
>> An: Renato De Giovanni
>> Cc: pyw...@li...; tdw...@li...
>> Betreff: Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir:
>> capabilities
>>
>> 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 <re...@cr...> wrote:
>>
>> 	Hi,
>> =09
>> 	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
>> =09
>> 	On 17 Jul 2006 at 21:26, "D=F6ring, Markus" wrote:
>> =09
>> 	> 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
>> =09
>> 	_______________________________________________
>> 	tdwg-tapir mailing list
>> 	tdw...@li...
>> 	http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
>> <http://lists.tdwg.org/mailman/listinfo/tdwg-tapir>
>> =09
>>
>>
>>
> _______________________________________________
> tdwg-tapir mailing list
> tdw...@li...
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir