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

[<m.d...@BG...>]

John,
all changes going on with TAPIR right now are really only changes in =
terminology or removing inconsistencies we did not detect before we =
started the documentation and final implementation.


But nevertheless I would support your request. Especially from the =
implementation side of view this is a trivial change to the code. So why =
dont add it? Just some additional thoughts:


- Ive added a "simulation" mode already to my code where no SQL gets =
executed but just logged. So you can test configurations without risking =
sending off killer statements. Thats similar to logOnly I guess, =
returning nothing but diagnostics. What would you suggest to be returned =
for a logOnly request? just the empty TAPIR envelope? Nothing? <OK>?

- would this log-only request not be needed for all requests? at least =
for inventories? So it would be easiest to have a new logOnly parameter =
in the header or "request element" just after the header? something like =
<search logOnly=3D"true">



-- Markus
 =20

> -----Urspr=FCngliche Nachricht-----
> Von: pyw...@li...=20
> [mailto:pyw...@li...] Im=20
> 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:=20
> capabilities
>=20
> A little off topic, but it occurs to me that a great deal of=20
> work is still ongoing with TAPIR, which suggests to me that=20
> it may be warranted to re-state my request for a simple=20
> message type - a log request. This request would be the same=20
> as a search request, except that the caller doesn't need a=20
> response. Providers would use this type of request to log=20
> data usage if the data were retrieved from a cache elsewhere.=20
> I remember talking about this in Berlin, at which time there=20
> was supposed to be a feature freeze. Clearly we've gone=20
> beyond that, so I'm requesting it again.=20
>=20
>=20
> On 7/17/06, Renato De Giovanni <re...@cr...> wrote:
>=20
> 	Hi,
> =09
> 	If I remember well, the "view" operation was re-included in the
> 	protocol just to handle query templates, especifically=20
> for TapirLite
> 	providers. So if someone wants to query a provider using some=20
> 	external output model that should be dynamically=20
> parsed, then the
> 	"search" operation must be used instead (using either=20
> XML or simple
> 	GET request). View operations are really bound to query=20
> templates,
> 	and they are not allowed to specify "filter" or=20
> "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=20
> that output models=20
> 	> are only specified for searches. but what about=20
> views? they use
> 	> query templates, yes. but only the ones listed in=20
> capabilities? we
> 	> should have dynamic ones here as well I think. And=20
> they link back to=20
> 	> static/dynamic models.
> 	>
> 	> So should models maybe become a seperate section not tight to
> 	> search/view operations? I am going to modify the=20
> schema nevertheless
> 	> already to accomodate the changes below - ignoring=20
> views for now.=20
> 	>
> 	> Markus
> =09
> 	_______________________________________________
> 	tdwg-tapir mailing list
> 	tdw...@li...
> 	http://lists.tdwg.org/mailman/listinfo/tdwg-tapir=20
> <http://lists.tdwg.org/mailman/listinfo/tdwg-tapir>=20
> =09
>=20
>=20
>=20