pywrapper-devel Mailing List for pywrapper (Page 10)
Status: Alpha
Brought to you by:
jatorre
Menu
▾
▴
pywrapper-devel — PyWrapper Developers mailing list
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
(10) |
Apr
|
May
(4) |
Jun
|
Jul
(40) |
Aug
(20) |
Sep
|
Oct
(10) |
Nov
(112) |
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(8) |
Feb
|
Mar
|
Apr
(6) |
May
(13) |
Jun
(12) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(3) |
| 2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(3) |
Jun
(3) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: John R. W. <tu...@be...> - 2006-07-27 16:57:49
|
That looks great to me. Thanks for your consideration of this request. On 7/27/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > > I have implemented the log-only request now and would like to suggest the > following: > > 1) add "log-only" attribute to responeOperationGroup. Ive chosen > "log-only" cause we already have there an attribute "apply-xslt" > 2) add a mandatory boolean attribute "logRequestsDenied" to the operation > element in a capabilities request > 3) use existing responses for the log-only request. So if you do a search > with log-only active, you will get an empty search response back. Thats m= uch > easier to implement and doesnt require any change in the schema. The same > works with inventories. Pong, Capa & Meta responses dont cost much anyway= , > so we could do a normal response (if anyway uses log-only with those > requests at all) > > > Does everyone agree to this? > The schema is already updated for this. > > > Markus > > > > -----Original Message----- > From: pyw...@li... on behalf of John R= . > WIECZOREK > Sent: Tue 7/25/2006 5:29 PM > To: D=F6ring, Markus > Cc: PyWrapper Developers mailing list; ro...@td...; > tdw...@li... > Subject: Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir: > capabilities > > Why make this so hard? We're talking about a portal sending out one > message > to n providers and not having to wait for a response. Right now we would > have to send out a message and wait for all of the responses (up to a > timeout). This is a net improvement. > > Why do we need metadata from providers to know if they want logging > requests? We don't ask them if they want metadata requests, or how often. > Just send the requests. If they want to log them, they will configure > their > provider to do so. Otherwise the provider will ignore them. > > In the meantime, always log on the portal side. Not only will that give > providers with flakey connections a place to see usage statistics, but it > will also generate information will be interesting on its own - summary > information about how the portal is used that you wouldn't get from the > providers. > > To me, this usage business is important enough that I would even go so fa= r > as to certify portals as being in compliance with meeting this social > contract. That way a provider could release access to certified portals > and > disallow access for those who don't abide by the contract. Remember, the > semblance of control is really important to a lot of our providers. If yo= u > don't think so, have someone do a survey of existing providers to see if > they would want it or not. It would be a sample biased against needing > logging (since they are already doing without). If that survey turned up > interest in logging anyway, then it's worth doing. My feeling is that it > is > so easy to implement (if you don't try to get unnecessarily fancy) that i= t > should just be done - it would be easier than conducting a survey about > it. > > On 7/25/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > > > > I agree that logging via GUID doesnt help in many cases where the > provider > > wants to know what was searched for. > > > > But searching on a portal-cache to find data from 20 different provider= s > > in 1 search and then sending of 20 log requests could also be annoying. > Plus > > the burden of the portal of checking the registry if a providers really > > wants logging. > > > > The most efficient is probably a portal specific logging as Donald > > suggests. But then providers would have a hard time agglomerating the > > logging data from several totaly different portals. > > > > To get a comparable logging across different portals though it seems to > me > > that Renatos suggestions are worth a try. It would definitely need > guidlines > > for portal developers to know when to use a log request and how to use > it. > > How to treat paging and map data are good examples where there is no > obvious > > correct behaviour. > > > > > > -- Markus > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: tdw...@li... > > > [mailto:tdw...@li...] Im Auftrag von > > > John R. WIECZOREK > > > Gesendet: Montag, 24. Juli 2006 18:28 > > > An: ro...@td... > > > Cc: PyWrapper Developers mailing list; tdw...@li... > > > Betreff: Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir: > > > capabilities > > > > > > Logging that a GUID was used isn't sufficient; it doesn't > > > tell how the data were used. What I'm after is to log the > > > actual query that would have had to go to the provider to > > > produce the results used. The example in your second example > > > shouldn't happen, the query should specify a record limit per > > > provider. > > > > > > > > > On 7/24/06, Roger Hyam <ro...@td...> wrote: > > > > > > > > > I thought this sounded like a good idea but since > > > reading Renato's message I am now confused. > > > > > > If a user does a search on a portal and gets 100 > > > results and looks at the first 10 does the provider of the > > > 11th record get notified? Their data has been used because it > > > has been given in the count. Another example would be if a > > > portal gave a distribution map to 10km squares based in data > > > from multiple providers. Each data point is made from several > > > suppliers data and removal of any one supplier's data may not > > > change the map. Do we notify them all? > > > > > > I could envisage a GUID based system just about. The > > > call to the log function would basically say "Some one has > > > accessed the data that I got from you that you tag with this > > > GUID" but I can't see how this would work on a search based > > > system. The log call would mean "Some one searched for > > > something that made used of data I got from a search I did on > > > you once". > > > > > > So really the only service we need is a GUID based one. > > > Perhaps extending the LSID resolution spec would be more appropriate? > > > > > > Roger > > > > > > > > > > > > Renato De Giovanni wrote: > > > > > > Hi John, > > > > > > Implementing the log request was never a > > > problem. We discussed about > > > that again during the Madrid meeting, and only > > > after that a feature > > > freeze was suggested. It's true that PyWrapper > > > is being adjusted now > > > > > > to conform to the new specs, and considering > > > that DiGIR2 (or wasabi) > > > postponed implementation of TAPIR, I suppose it > > > should not be a big > > > problem to make additional changes if necessary. > > > > > > The main problem I had with the log request was > > > that it would > > > > > > probably not solve the issue behind it, which > > > is to track usage by > > > data aggregators. I still have the same > > > feeling, and I can easily > > > imagine situations when it would not be easy or > > > even possible to > > > translate searches on top of cached databases > > > to TAPIR requests. > > > > > > > > > But maybe I'm wrong, and if you all think it's > > > a good feature then we > > > can try to include it. However, I do think that > > > providers should be > > > able to advertise as the part of capabilities > > > if they want to receive > > > > > > log requests or not. > > > > > > To me it also sounds like a new operation, > > > especially if it's only > > > related to search. It could make sense for > > > view, inventory and > > > metadata operations. Maybe capabilities too. > > > But it doesn't make > > > > > > sense for ping. Well, maybe it could make sense > > > for ping if the data > > > aggregator monitors provider status and accepts > > > similar requests on > > > top of its results... > > > > > > So, yes, it could be a new attribute "logOnly" > > > as part of the > > > > > > operationRequestGroup with an answer > > > </received> (just after the > > > response header). And we could add an attribute > > > "acceptLogRequests" > > > in the <operations> element in capabilities > > > responses. The other > > > > > > option would be to include a new operation, but > > > maybe it's better to > > > just have it as an optional attribute for all > > > operations. > > > > > > Best Regards, > > > -- > > > Renato > > > > > > On 19 Jul 2006 at 10:32, John R. WIECZOREK wrote: > > > > > > > > > > > > I appreciate that you will consider > > > this request. I always thought > > > it > > > would be trivial to implement. Your > > > simulation mode sounds very much > > > like what I had in mind. I hadn't > > > thought it necessary to get a > > > > > > response from a log request, but if > > > there was a simple response, it > > > could be used as a ping, or it could be > > > used to retry logging until > > > the provider did respond. So, something > > > like <log request received>. > > > > > > I think the addition oflogOnly > > > attribute is a good one, and could > > > apply to every request type. > > > > > > Javi, I don't disagree that portals > > > SHOULD log the data usage, > > > especially to cover the situations > > > where a provider doesn't respond. > > > > > > I also think that having the > > > information logged at the provider is a > > > responsible course of action, since > > > they will have immediate access > > > to the usage statistics that way. It > > > will be much easier for a > > > portal > > > > > > builder to send log requests than it > > > will be to build the > > > infrastructure and interfaces to logs, > > > therefore it is more likely > > > to > > > actually get done. > > > > > > > > > On 7/18/06, Javier de la Torre > > > <ja...@mn...> > > > <mailto:ja...@mn...> wrote: > > > I am not sure about this, > > > > > > I still think that portals should > > > be gathering this data and > > > making > > > it available for data providers... > > > > > > But in any case if you like it then > > > I agree with MArkus that the > > > > > > best > > > is to include another parameter in > > > the operationRequestGroup. > > > > > > I havent checked but what happens > > > if you do an extension there > > > with > > > an attribute that is implementation > > > specific? A qualified > > > > > > attribute. > > > Will this still validate against > > > our schema? You were > > > discussing > > > 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 > > > > 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 > > > > > > > > > > > >> -----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... > > > <mailto:pyw...@li...> ; tdwg- > > > ta...@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...> > > > <mailto:re...@cr...> 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=F6ring, > > > 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 > > > > > > tdw...@li... > > > <mailto:tdw...@li...> > > > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > > > > > > > > > > > > > > > > > > > > > -- > > > > > > ------------------------------------- > > > Roger Hyam > > > Technical Architect > > > Taxonomic Databases Working Group > > > ------------------------------------- > > > > > > http://www.tdwg.org <http://www.tdwg.org> > > > ro...@td... > > > +44 1578 722782 > > > ------------------------------------- > > > > > > _______________________________________________ > > > tdwg-tapir mailing list > > > tdw...@li... > > > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > > > <http://lists.tdwg.org/mailman/listinfo/tdwg-tapir> > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > tdwg-tapir mailing list > > tdw...@li... > > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > > > > > > |
|
From: <m.d...@BG...> - 2006-07-27 14:45:52
|
I have implemented the log-only request now and would like to suggest = the following: 1) add "log-only" attribute to responeOperationGroup. Ive chosen = "log-only" cause we already have there an attribute "apply-xslt" 2) add a mandatory boolean attribute "logRequestsDenied" to the = operation element in a capabilities request 3) use existing responses for the log-only request. So if you do a = search with log-only active, you will get an empty search response back. = Thats much easier to implement and doesnt require any change in the = schema. The same works with inventories. Pong, Capa & Meta responses = dont cost much anyway, so we could do a normal response (if anyway uses = log-only with those requests at all) Does everyone agree to this? The schema is already updated for this. Markus -----Original Message----- From: pyw...@li... on behalf of John R. = WIECZOREK Sent: Tue 7/25/2006 5:29 PM To: D=F6ring, Markus Cc: PyWrapper Developers mailing list; ro...@td...; = tdw...@li... Subject: Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir: capabilities Why make this so hard? We're talking about a portal sending out one = message to n providers and not having to wait for a response. Right now we would have to send out a message and wait for all of the responses (up to a timeout). This is a net improvement. Why do we need metadata from providers to know if they want logging requests? We don't ask them if they want metadata requests, or how = often. Just send the requests. If they want to log them, they will configure = their provider to do so. Otherwise the provider will ignore them. In the meantime, always log on the portal side. Not only will that give providers with flakey connections a place to see usage statistics, but = it will also generate information will be interesting on its own - summary information about how the portal is used that you wouldn't get from the providers. To me, this usage business is important enough that I would even go so = far as to certify portals as being in compliance with meeting this social contract. That way a provider could release access to certified portals = and disallow access for those who don't abide by the contract. Remember, the semblance of control is really important to a lot of our providers. If = you don't think so, have someone do a survey of existing providers to see if they would want it or not. It would be a sample biased against needing logging (since they are already doing without). If that survey turned up interest in logging anyway, then it's worth doing. My feeling is that it = is so easy to implement (if you don't try to get unnecessarily fancy) that = it should just be done - it would be easier than conducting a survey about = it. On 7/25/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > > I agree that logging via GUID doesnt help in many cases where the = provider > wants to know what was searched for. > > But searching on a portal-cache to find data from 20 different = providers > in 1 search and then sending of 20 log requests could also be = annoying. Plus > the burden of the portal of checking the registry if a providers = really > wants logging. > > The most efficient is probably a portal specific logging as Donald > suggests. But then providers would have a hard time agglomerating the > logging data from several totaly different portals. > > To get a comparable logging across different portals though it seems = to me > that Renatos suggestions are worth a try. It would definitely need = guidlines > for portal developers to know when to use a log request and how to use = it. > How to treat paging and map data are good examples where there is no = obvious > correct behaviour. > > > -- Markus > > > > -----Urspr=FCngliche Nachricht----- > > Von: tdw...@li... > > [mailto:tdw...@li...] Im Auftrag von > > John R. WIECZOREK > > Gesendet: Montag, 24. Juli 2006 18:28 > > An: ro...@td... > > Cc: PyWrapper Developers mailing list; tdw...@li... > > Betreff: Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir: > > capabilities > > > > Logging that a GUID was used isn't sufficient; it doesn't > > tell how the data were used. What I'm after is to log the > > actual query that would have had to go to the provider to > > produce the results used. The example in your second example > > shouldn't happen, the query should specify a record limit per > > provider. > > > > > > On 7/24/06, Roger Hyam <ro...@td...> wrote: > > > > > > I thought this sounded like a good idea but since > > reading Renato's message I am now confused. > > > > If a user does a search on a portal and gets 100 > > results and looks at the first 10 does the provider of the > > 11th record get notified? Their data has been used because it > > has been given in the count. Another example would be if a > > portal gave a distribution map to 10km squares based in data > > from multiple providers. Each data point is made from several > > suppliers data and removal of any one supplier's data may not > > change the map. Do we notify them all? > > > > I could envisage a GUID based system just about. The > > call to the log function would basically say "Some one has > > accessed the data that I got from you that you tag with this > > GUID" but I can't see how this would work on a search based > > system. The log call would mean "Some one searched for > > something that made used of data I got from a search I did on > > you once". > > > > So really the only service we need is a GUID based one. > > Perhaps extending the LSID resolution spec would be more = appropriate? > > > > Roger > > > > > > > > Renato De Giovanni wrote: > > > > Hi John, > > > > Implementing the log request was never a > > problem. We discussed about > > that again during the Madrid meeting, and only > > after that a feature > > freeze was suggested. It's true that PyWrapper > > is being adjusted now > > > > to conform to the new specs, and considering > > that DiGIR2 (or wasabi) > > postponed implementation of TAPIR, I suppose it > > should not be a big > > problem to make additional changes if necessary. > > > > The main problem I had with the log request was > > that it would > > > > probably not solve the issue behind it, which > > is to track usage by > > data aggregators. I still have the same > > feeling, and I can easily > > imagine situations when it would not be easy or > > even possible to > > translate searches on top of cached databases > > to TAPIR requests. > > > > > > But maybe I'm wrong, and if you all think it's > > a good feature then we > > can try to include it. However, I do think that > > providers should be > > able to advertise as the part of capabilities > > if they want to receive > > > > log requests or not. > > > > To me it also sounds like a new operation, > > especially if it's only > > related to search. It could make sense for > > view, inventory and > > metadata operations. Maybe capabilities too. > > But it doesn't make > > > > sense for ping. Well, maybe it could make sense > > for ping if the data > > aggregator monitors provider status and accepts > > similar requests on > > top of its results... > > > > So, yes, it could be a new attribute "logOnly" > > as part of the > > > > operationRequestGroup with an answer > > </received> (just after the > > response header). And we could add an attribute > > "acceptLogRequests" > > in the <operations> element in capabilities > > responses. The other > > > > option would be to include a new operation, but > > maybe it's better to > > just have it as an optional attribute for all > > operations. > > > > Best Regards, > > -- > > Renato > > > > On 19 Jul 2006 at 10:32, John R. WIECZOREK wrote: > > > > > > > > I appreciate that you will consider > > this request. I always thought > > it > > would be trivial to implement. Your > > simulation mode sounds very much > > like what I had in mind. I hadn't > > thought it necessary to get a > > > > response from a log request, but if > > there was a simple response, it > > could be used as a ping, or it could be > > used to retry logging until > > the provider did respond. So, something > > like <log request received>. > > > > I think the addition oflogOnly > > attribute is a good one, and could > > apply to every request type. > > > > Javi, I don't disagree that portals > > SHOULD log the data usage, > > especially to cover the situations > > where a provider doesn't respond. > > > > I also think that having the > > information logged at the provider is a > > responsible course of action, since > > they will have immediate access > > to the usage statistics that way. It > > will be much easier for a > > portal > > > > builder to send log requests than it > > will be to build the > > infrastructure and interfaces to logs, > > therefore it is more likely > > to > > actually get done. > > > > > > On 7/18/06, Javier de la Torre > > <ja...@mn...> > > <mailto:ja...@mn...> wrote: > > I am not sure about this, > > > > I still think that portals should > > be gathering this data and > > making > > it available for data providers... > > > > But in any case if you like it then > > I agree with MArkus that the > > > > best > > is to include another parameter in > > the operationRequestGroup. > > > > I havent checked but what happens > > if you do an extension there > > with > > an attribute that is implementation > > specific? A qualified > > > > attribute. > > Will this still validate against > > our schema? You were > > discussing > > 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 > > > 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 > > > > > > > > >> -----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... > > <mailto:pyw...@li...> ; tdwg- > > ta...@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...> > > <mailto:re...@cr...> 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=F6ring, > > 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 > > > > tdw...@li... > > <mailto:tdw...@li...> > > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > > > > > > > > > > > > > > -- > > > > ------------------------------------- > > Roger Hyam > > Technical Architect > > Taxonomic Databases Working Group > > ------------------------------------- > > > > http://www.tdwg.org <http://www.tdwg.org> > > ro...@td... > > +44 1578 722782 > > ------------------------------------- > > > > _______________________________________________ > > tdwg-tapir mailing list > > tdw...@li... > > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > > <http://lists.tdwg.org/mailman/listinfo/tdwg-tapir> > > > > > > > > > > > > > _______________________________________________ > tdwg-tapir mailing list > tdw...@li... > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > |
|
From: <wi...@go...> - 2006-07-27 11:38:15
|
hi, id like to implement searching on schema enumerations. I allow to setup a translation between local database terms and schema/concept terms. So when searching I need to translate the argument as well. Thats horrible for LIKEs. So I will only allow an equal operation for now on enumerations. Do you think this is very bad? Markus |
|
From: Javier de la T. <ja...@gm...> - 2006-07-27 11:35:23
|
Is there any sense for doing a like in an enumeration? I think equals is more than enough and probably more correct. Javi. On 7/27/06, Markus D=F6ring <wi...@go...> wrote: > hi, > id like to implement searching on schema enumerations. > I allow to setup a translation between local database terms and > schema/concept terms. > So when searching I need to translate the argument as well. Thats horribl= e > for LIKEs. So I will only allow an equal operation for now on enumeration= s. > Do you think this is very bad? > > Markus > > |
|
From: <wi...@go...> - 2006-07-27 11:33:27
|
you might want to get all "XXXSpecimen" as opposed to "XXXObservation" you could do LIKE '*Specimen' well, but its not needed for living. in PyWrapper this will be an error. sorry. M On 7/27/06, Javier de la Torre <ja...@gm...> wrote: > > Is there any sense for doing a like in an enumeration? > > I think equals is more than enough and probably more correct. > > Javi. > > On 7/27/06, Markus D=F6ring <wi...@go...> wrote: > > hi, > > id like to implement searching on schema enumerations. > > I allow to setup a translation between local database terms and > > schema/concept terms. > > So when searching I need to translate the argument as well. Thats > horrible > > for LIKEs. So I will only allow an equal operation for now on > enumerations. > > Do you think this is very bad? > > > > Markus > > > > > |
|
From: Javier de la T. <ja...@gm...> - 2006-07-27 11:30:16
|
Hi, Actually there is no editor for the metadata in the PyWrapper configuration tool. The metadata is stored in an XML document comformant to the TAPIR XML schema. It looks like the perfect scenario to try XForms. We read the XML schema to generate the HTML with the form to edit and then we serialize with XUpdate to update the XML document... In a perfect world this would be automatically done and we would not have to program anything, but... anybody has tried something like this? Here is a list of XForms implementations: http://www.w3.org/MarkUp/Forms/#implementations And here are two funny projects that I dont think we can consider but that I find curious. http://bitfluxeditor.org/demo/ http://xopus.com/demo/ Cheers. |
|
From: John R. W. <tu...@be...> - 2006-07-25 15:29:40
|
Why make this so hard? We're talking about a portal sending out one message to n providers and not having to wait for a response. Right now we would have to send out a message and wait for all of the responses (up to a timeout). This is a net improvement. Why do we need metadata from providers to know if they want logging requests? We don't ask them if they want metadata requests, or how often. Just send the requests. If they want to log them, they will configure their provider to do so. Otherwise the provider will ignore them. In the meantime, always log on the portal side. Not only will that give providers with flakey connections a place to see usage statistics, but it will also generate information will be interesting on its own - summary information about how the portal is used that you wouldn't get from the providers. To me, this usage business is important enough that I would even go so far as to certify portals as being in compliance with meeting this social contract. That way a provider could release access to certified portals and disallow access for those who don't abide by the contract. Remember, the semblance of control is really important to a lot of our providers. If you don't think so, have someone do a survey of existing providers to see if they would want it or not. It would be a sample biased against needing logging (since they are already doing without). If that survey turned up interest in logging anyway, then it's worth doing. My feeling is that it is so easy to implement (if you don't try to get unnecessarily fancy) that it should just be done - it would be easier than conducting a survey about it. On 7/25/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > > I agree that logging via GUID doesnt help in many cases where the provide= r > wants to know what was searched for. > > But searching on a portal-cache to find data from 20 different providers > in 1 search and then sending of 20 log requests could also be annoying. P= lus > the burden of the portal of checking the registry if a providers really > wants logging. > > The most efficient is probably a portal specific logging as Donald > suggests. But then providers would have a hard time agglomerating the > logging data from several totaly different portals. > > To get a comparable logging across different portals though it seems to m= e > that Renatos suggestions are worth a try. It would definitely need guidli= nes > for portal developers to know when to use a log request and how to use it= . > How to treat paging and map data are good examples where there is no obvi= ous > correct behaviour. > > > -- Markus > > > > -----Urspr=FCngliche Nachricht----- > > Von: tdw...@li... > > [mailto:tdw...@li...] Im Auftrag von > > John R. WIECZOREK > > Gesendet: Montag, 24. Juli 2006 18:28 > > An: ro...@td... > > Cc: PyWrapper Developers mailing list; tdw...@li... > > Betreff: Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir: > > capabilities > > > > Logging that a GUID was used isn't sufficient; it doesn't > > tell how the data were used. What I'm after is to log the > > actual query that would have had to go to the provider to > > produce the results used. The example in your second example > > shouldn't happen, the query should specify a record limit per > > provider. > > > > > > On 7/24/06, Roger Hyam <ro...@td...> wrote: > > > > > > I thought this sounded like a good idea but since > > reading Renato's message I am now confused. > > > > If a user does a search on a portal and gets 100 > > results and looks at the first 10 does the provider of the > > 11th record get notified? Their data has been used because it > > has been given in the count. Another example would be if a > > portal gave a distribution map to 10km squares based in data > > from multiple providers. Each data point is made from several > > suppliers data and removal of any one supplier's data may not > > change the map. Do we notify them all? > > > > I could envisage a GUID based system just about. The > > call to the log function would basically say "Some one has > > accessed the data that I got from you that you tag with this > > GUID" but I can't see how this would work on a search based > > system. The log call would mean "Some one searched for > > something that made used of data I got from a search I did on > > you once". > > > > So really the only service we need is a GUID based one. > > Perhaps extending the LSID resolution spec would be more appropriate? > > > > Roger > > > > > > > > Renato De Giovanni wrote: > > > > Hi John, > > > > Implementing the log request was never a > > problem. We discussed about > > that again during the Madrid meeting, and only > > after that a feature > > freeze was suggested. It's true that PyWrapper > > is being adjusted now > > > > to conform to the new specs, and considering > > that DiGIR2 (or wasabi) > > postponed implementation of TAPIR, I suppose it > > should not be a big > > problem to make additional changes if necessary. > > > > The main problem I had with the log request was > > that it would > > > > probably not solve the issue behind it, which > > is to track usage by > > data aggregators. I still have the same > > feeling, and I can easily > > imagine situations when it would not be easy or > > even possible to > > translate searches on top of cached databases > > to TAPIR requests. > > > > > > But maybe I'm wrong, and if you all think it's > > a good feature then we > > can try to include it. However, I do think that > > providers should be > > able to advertise as the part of capabilities > > if they want to receive > > > > log requests or not. > > > > To me it also sounds like a new operation, > > especially if it's only > > related to search. It could make sense for > > view, inventory and > > metadata operations. Maybe capabilities too. > > But it doesn't make > > > > sense for ping. Well, maybe it could make sense > > for ping if the data > > aggregator monitors provider status and accepts > > similar requests on > > top of its results... > > > > So, yes, it could be a new attribute "logOnly" > > as part of the > > > > operationRequestGroup with an answer > > </received> (just after the > > response header). And we could add an attribute > > "acceptLogRequests" > > in the <operations> element in capabilities > > responses. The other > > > > option would be to include a new operation, but > > maybe it's better to > > just have it as an optional attribute for all > > operations. > > > > Best Regards, > > -- > > Renato > > > > On 19 Jul 2006 at 10:32, John R. WIECZOREK wrote: > > > > > > > > I appreciate that you will consider > > this request. I always thought > > it > > would be trivial to implement. Your > > simulation mode sounds very much > > like what I had in mind. I hadn't > > thought it necessary to get a > > > > response from a log request, but if > > there was a simple response, it > > could be used as a ping, or it could be > > used to retry logging until > > the provider did respond. So, something > > like <log request received>. > > > > I think the addition oflogOnly > > attribute is a good one, and could > > apply to every request type. > > > > Javi, I don't disagree that portals > > SHOULD log the data usage, > > especially to cover the situations > > where a provider doesn't respond. > > > > I also think that having the > > information logged at the provider is a > > responsible course of action, since > > they will have immediate access > > to the usage statistics that way. It > > will be much easier for a > > portal > > > > builder to send log requests than it > > will be to build the > > infrastructure and interfaces to logs, > > therefore it is more likely > > to > > actually get done. > > > > > > On 7/18/06, Javier de la Torre > > <ja...@mn...> > > <mailto:ja...@mn...> wrote: > > I am not sure about this, > > > > I still think that portals should > > be gathering this data and > > making > > it available for data providers... > > > > But in any case if you like it then > > I agree with MArkus that the > > > > best > > is to include another parameter in > > the operationRequestGroup. > > > > I havent checked but what happens > > if you do an extension there > > with > > an attribute that is implementation > > specific? A qualified > > > > attribute. > > Will this still validate against > > our schema? You were > > discussing > > 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 > > > 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 > > > > > > > > >> -----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... > > <mailto:pyw...@li...> ; tdwg- > > ta...@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...> > > <mailto:re...@cr...> 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=F6ring, > > 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 > > > > tdw...@li... > > <mailto:tdw...@li...> > > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > > > > > > > > > > > > > > -- > > > > ------------------------------------- > > Roger Hyam > > Technical Architect > > Taxonomic Databases Working Group > > ------------------------------------- > > > > http://www.tdwg.org <http://www.tdwg.org> > > ro...@td... > > +44 1578 722782 > > ------------------------------------- > > > > _______________________________________________ > > tdwg-tapir mailing list > > tdw...@li... > > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > > <http://lists.tdwg.org/mailman/listinfo/tdwg-tapir> > > > > > > > > > > > > > _______________________________________________ > tdwg-tapir mailing list > tdw...@li... > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > |
|
From: <m.d...@BG...> - 2006-07-25 12:19:55
|
Yes, I think I like it like that.=20 So the last one to be sure. An envelopeless counting search will ignore = the count or turn on the envelope? coffee and Ill be back... -- Markus =20 > -----Urspr=FCngliche Nachricht----- > Von: pyw...@li...=20 > [mailto:pyw...@li...] Im=20 > Auftrag von Renato De Giovanni > Gesendet: Dienstag, 25. Juli 2006 13:42 > An: PyWrapper Developers mailing list > Betreff: Re: [PyWrapper-devel] tapir get requests & views >=20 > Hi Markus, >=20 > Sorry, you're right about this. I'm talking with Javier now,=20 > and our suggestion is: >=20 > * envelopeless responses only allowed for search operations. > * the content will be what goes inside <search>, so it will=20 > exclude <summary>. I think we can assume that the client=20 > knows what he/she is doing. > If paging is necessary (which is a TAPIR feature) then=20 > envelope needs to turned on. >=20 > Is that OK? >=20 > Regards, > -- > Renato >=20 > > Hello, > > turning off the envelope meant for me only to return the=20 > pure content=20 > > - for example an ABCD record. It was mainly inspired to=20 > have a "view"=20 > > on a single ID to get only the XML describing the object. Or to get=20 > > pure RSS or KML for several objects. > > > > If its only to turn off the header and diagnostics I think=20 > we wouldnt=20 > > need it, a client would have to deal with TAPIR anyway. > > > > > > -- Markus >=20 >=20 >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV > _______________________________________________ > PyWrapper-devel mailing list > PyW...@li... > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel >=20 |
|
From: Renato De G. <re...@cr...> - 2006-07-25 11:41:58
|
Hi Markus, Sorry, you're right about this. I'm talking with Javier now, and our suggestion is: * envelopeless responses only allowed for search operations. * the content will be what goes inside <search>, so it will exclude <summary>. I think we can assume that the client knows what he/she is doing. If paging is necessary (which is a TAPIR feature) then envelope needs to turned on. Is that OK? Regards, -- Renato > Hello, > turning off the envelope meant for me only to return the pure content - > for example an ABCD record. It was mainly inspired to have a "view" on a > single ID to get only the XML describing the object. Or to get pure RSS or > KML for several objects. > > If its only to turn off the header and diagnostics I think we wouldnt need > it, a client would have to deal with TAPIR anyway. > > > -- Markus |
|
From: <m.d...@BG...> - 2006-07-25 09:54:34
|
I agree that logging via GUID doesnt help in many cases where the = provider wants to know what was searched for. But searching on a portal-cache to find data from 20 different providers = in 1 search and then sending of 20 log requests could also be annoying. = Plus the burden of the portal of checking the registry if a providers = really wants logging. The most efficient is probably a portal specific logging as Donald = suggests. But then providers would have a hard time agglomerating the = logging data from several totaly different portals. To get a comparable logging across different portals though it seems to = me that Renatos suggestions are worth a try. It would definitely need = guidlines for portal developers to know when to use a log request and = how to use it. How to treat paging and map data are good examples where = there is no obvious correct behaviour. -- Markus =20 > -----Urspr=FCngliche Nachricht----- > Von: tdw...@li...=20 > [mailto:tdw...@li...] Im Auftrag von=20 > John R. WIECZOREK > Gesendet: Montag, 24. Juli 2006 18:28 > An: ro...@td... > Cc: PyWrapper Developers mailing list; tdw...@li... > Betreff: Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir:=20 > capabilities >=20 > Logging that a GUID was used isn't sufficient; it doesn't=20 > tell how the data were used. What I'm after is to log the=20 > actual query that would have had to go to the provider to=20 > produce the results used. The example in your second example=20 > shouldn't happen, the query should specify a record limit per=20 > provider. >=20 >=20 > On 7/24/06, Roger Hyam <ro...@td...> wrote: >=20 >=20 > I thought this sounded like a good idea but since=20 > reading Renato's message I am now confused. > =09 > If a user does a search on a portal and gets 100=20 > results and looks at the first 10 does the provider of the=20 > 11th record get notified? Their data has been used because it=20 > has been given in the count. Another example would be if a=20 > portal gave a distribution map to 10km squares based in data=20 > from multiple providers. Each data point is made from several=20 > suppliers data and removal of any one supplier's data may not=20 > change the map. Do we notify them all? > =09 > I could envisage a GUID based system just about. The=20 > call to the log function would basically say "Some one has=20 > accessed the data that I got from you that you tag with this=20 > GUID" but I can't see how this would work on a search based=20 > system. The log call would mean "Some one searched for=20 > something that made used of data I got from a search I did on=20 > you once". > =09 > So really the only service we need is a GUID based one.=20 > Perhaps extending the LSID resolution spec would be more appropriate? > =09 > Roger > =09 > =09 > =09 > Renato De Giovanni wrote:=20 >=20 > Hi John, > =09 > Implementing the log request was never a=20 > problem. We discussed about=20 > that again during the Madrid meeting, and only=20 > after that a feature=20 > freeze was suggested. It's true that PyWrapper=20 > is being adjusted now=20 > =09 > to conform to the new specs, and considering=20 > that DiGIR2 (or wasabi)=20 > postponed implementation of TAPIR, I suppose it=20 > should not be a big=20 > problem to make additional changes if necessary. > =09 > The main problem I had with the log request was=20 > that it would=20 > =09 > probably not solve the issue behind it, which=20 > is to track usage by=20 > data aggregators. I still have the same=20 > feeling, and I can easily=20 > imagine situations when it would not be easy or=20 > even possible to=20 > translate searches on top of cached databases=20 > to TAPIR requests. > =09 > =09 > But maybe I'm wrong, and if you all think it's=20 > a good feature then we=20 > can try to include it. However, I do think that=20 > providers should be=20 > able to advertise as the part of capabilities=20 > if they want to receive=20 > =09 > log requests or not.=20 > =09 > To me it also sounds like a new operation,=20 > especially if it's only=20 > related to search. It could make sense for=20 > view, inventory and=20 > metadata operations. Maybe capabilities too.=20 > But it doesn't make=20 > =09 > sense for ping. Well, maybe it could make sense=20 > for ping if the data=20 > aggregator monitors provider status and accepts=20 > similar requests on=20 > top of its results... > =09 > So, yes, it could be a new attribute "logOnly"=20 > as part of the=20 > =09 > operationRequestGroup with an answer=20 > </received> (just after the=20 > response header). And we could add an attribute=20 > "acceptLogRequests"=20 > in the <operations> element in capabilities=20 > responses. The other=20 > =09 > option would be to include a new operation, but=20 > maybe it's better to=20 > just have it as an optional attribute for all=20 > operations. > =09 > Best Regards, > -- > Renato > =09 > On 19 Jul 2006 at 10:32, John R. WIECZOREK wrote: > =09 > =20 >=20 > I appreciate that you will consider=20 > this request. I always thought > it=20 > would be trivial to implement. Your=20 > simulation mode sounds very much > like what I had in mind. I hadn't=20 > thought it necessary to get a=20 > =09 > response from a log request, but if=20 > there was a simple response, it > could be used as a ping, or it could be=20 > used to retry logging until > the provider did respond. So, something=20 > like <log request received>. > =09 > I think the addition oflogOnly=20 > attribute is a good one, and could=20 > apply to every request type.=20 > =09 > Javi, I don't disagree that portals=20 > SHOULD log the data usage,=20 > especially to cover the situations=20 > where a provider doesn't respond. > =09 > I also think that having the=20 > information logged at the provider is a > responsible course of action, since=20 > they will have immediate access > to the usage statistics that way. It=20 > will be much easier for a > portal=20 > =09 > builder to send log requests than it=20 > will be to build the=20 > infrastructure and interfaces to logs,=20 > therefore it is more likely > to=20 > actually get done.=20 > =09 > =09 > On 7/18/06, Javier de la Torre=20 > <ja...@mn...>=20 > <mailto:ja...@mn...> wrote:=20 > I am not sure about this, > =20 > I still think that portals should=20 > be gathering this data and > making > it available for data providers...=20 > =20 > But in any case if you like it then=20 > I agree with MArkus that the > =09 > best > is to include another parameter in=20 > the operationRequestGroup. > =20 > I havent checked but what happens=20 > if you do an extension there > with > an attribute that is implementation=20 > specific? A qualified > =09 > attribute. > Will this still validate against=20 > our schema? You were > discussing > about qualification of attributes before no? > =20 > Javi. > =20 > On 18/07/2006, at 10:41, D=F6ring,=20 > Markus wrote:=20 > =09 > =20 > > John, > > all changes going on with TAPIR=20 > right now are really only > changes > > in terminology or removing=20 > inconsistencies we did not detect > before > > we started the documentation and=20 > final implementation.=20 > =09 > > > > > > But nevertheless I would support=20 > your request. Especially from > the > > implementation side of view this=20 > is a trivial change to the > code. > > So why dont add it? Just some=20 > additional thoughts:=20 > =09 > > > > > > - Ive added a "simulation" mode=20 > already to my code where no > SQL > > gets executed but just logged. So=20 > you can test > configurations > > without risking sending off=20 > killer statements. Thats similar > =09 > to=20 > > logOnly I guess, returning=20 > nothing but diagnostics. What would > you > > suggest to be returned for a=20 > logOnly request? just the empty > TAPIR > > envelope? Nothing? <OK>? > > > =09 > > - would this log-only request not=20 > be needed for all requests? > at=20 > > least for inventories? So it=20 > would be easiest to have a new > logOnly > > parameter in the header or=20 > "request element" just after the > =09 > header? > > something like <search logOnly=3D"true"> > > > > > > > > -- Markus > > > > > >> -----Urspr=FCngliche Nachricht----- > >> Von:=20 > pyw...@li... > =20 > >>=20 > [mailto:pyw...@li... > ] Im > >> Auftrag von John R. WIECZOREK > >> Gesendet: Montag, 17. Juli 2006 23:30=20 > >> An: Renato De Giovanni > >> Cc:=20 > pyw...@li...=20 > <mailto:pyw...@li...> ; tdwg- > ta...@li... > =20 > >> Betreff: Re: [PyWrapper-devel]=20 > [tdwg-tapir] RE: WG: tapir: > >> capabilities > >> > >> A little off topic, but it=20 > occurs to me that a great deal > of > >> work is still ongoing with=20 > TAPIR, which suggests to me that > =09 > >> it may be warranted to re-state=20 > my request for a simple > >> message type - a log request.=20 > This request would be the > same > >> as a search request, except that=20 > the caller doesn't need a > =09 > >> response. Providers would use=20 > this type of request to log=20 > >> data usage if the data were=20 > retrieved from a cache > elsewhere. > >> I remember talking about this in=20 > Berlin, at which time > =09 > there > >> was supposed to be a feature=20 > freeze. Clearly we've gone > >> beyond that, so I'm requesting it again.=20 > >> > >> > >> On 7/17/06, Renato De Giovanni=20 > <re...@cr...>=20 > <mailto:re...@cr...> wrote: > >> > >>Hi, > >> > >>If I remember well, the "view"=20 > operation was re-included in=20 > the=20 > >>protocol just to handle query=20 > templates, especifically > =09 > >> for TapirLite > >>providers. So if someone wants to=20 > query a provider using > some > >>external output model that should=20 > be dynamically=20 > >> parsed, then the > >>"search" operation must be used=20 > instead (using either > =09 > >> XML or simple > >>GET request). View operations are=20 > really bound to query > >> templates,=20 > >>and they are not allowed to=20 > specify "filter" or > >> "partial" parameters. > =09 > >>-- > >>Renato > >> > >>On 17 Jul 2006 at 21:26, "D=F6ring,=20 > Markus" wrote:=20 > >> > >>> I was just about to edit the=20 > schema and realizing > =09 > >> that output models > >>> are only specified for=20 > searches. but what about > >> views? they use > >>> query templates, yes. but only=20 > the ones listed in=20 > >> capabilities? we > =09 > >>> should have dynamic ones here=20 > as well I think. And > >> they link back to > >>> static/dynamic models. > >>> > >>> So should models maybe become a=20 > seperate section not tight > =09 > to=20 > >>> search/view operations? I am=20 > going to modify the > >> schema nevertheless > >>> already to accomodate the=20 > changes below - ignoring > >> views for now. > =09 > >>> > >>> Markus > =20 >=20 > _______________________________________________ > tdwg-tapir mailing list > =09 > tdw...@li...=20 > <mailto:tdw...@li...>=20 > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > =09 > =09 > =20 >=20 >=20 >=20 > --=20 > =09 > ------------------------------------- > Roger Hyam > Technical Architect > Taxonomic Databases Working Group > ------------------------------------- > =20 > http://www.tdwg.org <http://www.tdwg.org>=20 > ro...@td... > +44 1578 722782 > ------------------------------------- >=20 > _______________________________________________ > 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 > =09 > =09 >=20 >=20 >=20 |
|
From: <m.d...@BG...> - 2006-07-25 09:28:50
|
Hello, turning off the envelope meant for me only to return the pure content - = for example an ABCD record. It was mainly inspired to have a "view" on a = single ID to get only the XML describing the object. Or to get pure RSS = or KML for several objects.=20 If its only to turn off the header and diagnostics I think we wouldnt = need it, a client would have to deal with TAPIR anyway. -- Markus =20 > -----Urspr=FCngliche Nachricht----- > Von: pyw...@li...=20 > [mailto:pyw...@li...] Im=20 > Auftrag von Renato De Giovanni > Gesendet: Mittwoch, 19. Juli 2006 21:53 > An: pyw...@li... > Betreff: Re: [PyWrapper-devel] tapir get requests & views >=20 > Hi, >=20 > > Im checking the GET invoked operations now and I cant remember the=20 > > reason why we introduced another view request. We should provide=20 > > Charles some arguments why it exists and why we didnt just include=20 > > template as a parameter in inventories and searches. What was wrong=20 > > about that? >=20 > As I said, the only reason for the view operation was to=20 > accommodate TAPIRLite providers. Apparently it was the=20 > easiest way to do that.=20 > Remeber their requirements: >=20 > * No need to parse XML requests (only GET requests with=20 > simple key/value parameters) > * No need to parse filters. > * No need to implement "partial". > * All queries based on templates. >=20 > There could be other ways to allow the existence of TAPIRLite=20 > without having the view operation, such as including many new=20 > attributes in the search operation capabilities, but it would=20 > easily get confusing and contradictory, I think. >=20 > Searches and inventories can make use of templates already,=20 > can't they? (at least in XML requests, but I don't see why=20 > not via GET requests as well). >=20 > > - is the envelope turned off or on when non view requests=20 > are called=20 > > via GET? I thought its turned off then. Am I right? >=20 > If this is not documented/defined somewhere I would suggest=20 > to turn on the envelope by default for all non view requests. >=20 > > - inventories without envelope need some embracing root=20 > element above=20 > > the <record> elements. So should we answer with <tapir:inventory> ? >=20 > I understood that turning off envelopes just meant removing=20 > header and diagnostics. The root element would still be <response>. >=20 > > - If so, shouldnt we do the same for the other operations (with=20 > > exception of views maybe - well, actually an inventory view has the=20 > > same problem!). If we would do so, the summary element for=20 > paging is=20 > > there as well and we would not need to turn on the entire=20 > envelope for=20 > > counts. > > - if not, what about ping? >=20 > Same answer above. > =20 > > Looks like I am discovering ever more little questions. > > Stay tuned. >=20 > No worries, let's kill them all! > -- > Renato >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV > _______________________________________________ > PyWrapper-devel mailing list > PyW...@li... > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel >=20 |
|
From: John R. W. <tu...@be...> - 2006-07-24 16:27:54
|
Logging that a GUID was used isn't sufficient; it doesn't tell how the data were used. What I'm after is to log the actual query that would have had to go to the provider to produce the results used. The example in your second example shouldn't happen, the query should specify a record limit per provider. On 7/24/06, Roger Hyam <ro...@td...> wrote: > > > I thought this sounded like a good idea but since reading Renato's messag= e > I am now confused. > > If a user does a search on a portal and gets 100 results and looks at the > first 10 does the provider of the 11th record get notified? Their data ha= s > been used because it has been given in the count. Another example would = be > if a portal gave a distribution map to 10km squares based in data from > multiple providers. Each data point is made from several suppliers data a= nd > removal of any one supplier's data may not change the map. Do we notify t= hem > all? > > I could envisage a GUID based system just about. The call to the log > function would basically say "Some one has accessed the data that I got f= rom > you that you tag with this GUID" but I can't see how this would work on a > search based system. The log call would mean "Some one searched for > something that made used of data I got from a search I did on you once". > > So really the only service we need is a GUID based one. Perhaps extending > the LSID resolution spec would be more appropriate? > > Roger > > > > Renato De Giovanni wrote: > > Hi John, > > Implementing the log request was never a problem. We discussed about > that again during the Madrid meeting, and only after that a feature > freeze was suggested. It's true that PyWrapper is being adjusted now > to conform to the new specs, and considering that DiGIR2 (or wasabi) > postponed implementation of TAPIR, I suppose it should not be a big > problem to make additional changes if necessary. > > The main problem I had with the log request was that it would > probably not solve the issue behind it, which is to track usage by > data aggregators. I still have the same feeling, and I can easily > imagine situations when it would not be easy or even possible to > translate searches on top of cached databases to TAPIR requests. > > But maybe I'm wrong, and if you all think it's a good feature then we > can try to include it. However, I do think that providers should be > able to advertise as the part of capabilities if they want to receive > log requests or not. > > To me it also sounds like a new operation, especially if it's only > related to search. It could make sense for view, inventory and > metadata operations. Maybe capabilities too. But it doesn't make > sense for ping. Well, maybe it could make sense for ping if the data > aggregator monitors provider status and accepts similar requests on > top of its results... > > So, yes, it could be a new attribute "logOnly" as part of the > operationRequestGroup with an answer </received> (just after the > response header). And we could add an attribute "acceptLogRequests" > in the <operations> element in capabilities responses. The other > option would be to include a new operation, but maybe it's better to > just have it as an optional attribute for all operations. > > Best Regards, > -- > Renato > > On 19 Jul 2006 at 10:32, John R. WIECZOREK wrote: > > I appreciate that you will consider this request. I always thought > it > would be trivial to implement. Your simulation mode sounds very much > like what I had in mind. I hadn't thought it necessary to get a > response from a log request, but if there was a simple response, it > could be used as a ping, or it could be used to retry logging until > the provider did respond. So, something like <log request received>. > I think the addition oflogOnly attribute is a good one, and could > apply to every request type. > > Javi, I don't disagree that portals SHOULD log the data usage, > especially to cover the situations where a provider doesn't respond. > I also think that having the information logged at the provider is a > responsible course of action, since they will have immediate access > to the usage statistics that way. It will be much easier for a > portal > builder to send log requests than it will be to build the > infrastructure and interfaces to logs, therefore it is more likely > to > actually get done. > > > On 7/18/06, Javier de la Torre <ja...@mn...> <jatorre@mncn.csic.= es> wrote: > I am not sure about this, > > I still think that portals should be gathering this data and > making > it available for data providers... > > But in any case if you like it then I agree with MArkus that the > best > is to include another parameter in the operationRequestGroup. > > I havent checked but what happens if you do an extension there > with > an attribute that is implementation specific? A qualified > attribute. > Will this still validate against our schema? You were > discussing > 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 > > 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 > > > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: pyw...@li... > >> [mailto:pyw...@li... <pywrapper-d= eve...@li...>] Im > >> Auftrag von John R. WIECZOREK > >> Gesendet: Montag, 17. Juli 2006 23:30 > >> An: Renato De Giovanni > >> Cc: pyw...@li...; tdwg- > ta...@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...> <renato@cria.o= rg.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=F6ring, 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 > tdw...@li...http://lists.tdwg.org/mailman/listinfo/tdwg-tapi= r > > > > -- > > ------------------------------------- > Roger Hyam > Technical Architect > Taxonomic Databases Working Group > ------------------------------------- > http://www.tdwg.org > ro...@td... > +44 1578 722782 > ------------------------------------- > > > _______________________________________________ > tdwg-tapir mailing list > tdw...@li... > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > > > |
|
From: Donald H. <dh...@gb...> - 2006-07-24 11:06:01
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I tend to agree that this will only really work in cases in which the
cache is structured and used precisely as a performance enhancement for
the same requests that are then forwarded with the logOnly attribute.
In other cases the mapping may be more or less meaningless and the
necessary traffic could be enormous (and hard to interpret)<br>
<br>
I'd rather see us putting the effort into thinking about the real
reporting needs of primary data providers and how we can meet them. I
obviously have this as a critical problem and will have to find
efficient and informative ways to notify providers of the usage of
their data at several different mirror sites (and ideally also at
various downstream portals). The range of different things that could
be worth reporting includes:<br>
<br>
<ol>
<li>We indexed/cached your resource (some or all records)</li>
<li>We showed a user the metadata for your resource</li>
<li>We showed a user a high-level map of the range of occurrences
from your resource</li>
<li>We showed a user a high-level map of the range of occurrences for
a taxon (or geographic region) including some of your records</li>
<li>We displayed a count of the records from your resource relating
to a taxon (or geographic region)</li>
<li>We showed a subset of fields from some records from your resource</li>
<li>We showed the full detail for some records from your resource
using a cached copy</li>
<li>We showed the full detail for some records from your resource
using a freshly accessed copy</li>
</ol>
There is also the issue of how to report that we have determined that
some records are relevant to a user request based on external taxonomic
or geographic knowledge (i.e. NOT using any fields that actually would
find the record on a TAPIR request to your resource).<br>
<br>
I think that logOnly could be a useful tool in some circumstances but
it cannot be the full picture.<br>
<br>
Donald<br>
<pre class="moz-signature" cols="72">------------------------------------------------------------
Donald Hobern (<a class="moz-txt-link-abbreviated" href="mailto:dh...@gb...">dh...@gb...</a>)
Deputy Director for Informatics
Global Biodiversity Information Facility Secretariat
Universitetsparken 15, DK-2100 Copenhagen, Denmark
Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480
------------------------------------------------------------
</pre>
<br>
<br>
Roger Hyam wrote:
<blockquote cite="mid...@td..." type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<br>
I thought this sounded like a good idea but since reading Renato's
message I am now confused.<br>
<br>
If a user does a search on a portal and gets 100 results and looks at
the first 10 does the provider of the 11th record get notified? Their
data has been used because it has been given in the count. Another
example would be if a portal gave a distribution map to 10km squares
based in data from multiple providers. Each data point is made from
several suppliers data and removal of any one supplier's data may not
change the map. Do we notify them all?<br>
<br>
I could envisage a GUID based system just about. The call to the log
function would basically say "Some one has accessed the data that I got
from you that you tag with this GUID" but I can't see how this would
work on a search based system. The log call would mean "Some one
searched for something that made used of data I got from a search I did
on you once".<br>
<br>
So really the only service we need is a GUID based one. Perhaps
extending the LSID resolution spec would be more appropriate?<br>
<br>
Roger<br>
<br>
<br>
Renato De Giovanni wrote:
<blockquote cite="mid...@re..."
type="cite">
<pre wrap="">Hi John,
Implementing the log request was never a problem. We discussed about
that again during the Madrid meeting, and only after that a feature
freeze was suggested. It's true that PyWrapper is being adjusted now
to conform to the new specs, and considering that DiGIR2 (or wasabi)
postponed implementation of TAPIR, I suppose it should not be a big
problem to make additional changes if necessary.
The main problem I had with the log request was that it would
probably not solve the issue behind it, which is to track usage by
data aggregators. I still have the same feeling, and I can easily
imagine situations when it would not be easy or even possible to
translate searches on top of cached databases to TAPIR requests.
But maybe I'm wrong, and if you all think it's a good feature then we
can try to include it. However, I do think that providers should be
able to advertise as the part of capabilities if they want to receive
log requests or not.
To me it also sounds like a new operation, especially if it's only
related to search. It could make sense for view, inventory and
metadata operations. Maybe capabilities too. But it doesn't make
sense for ping. Well, maybe it could make sense for ping if the data
aggregator monitors provider status and accepts similar requests on
top of its results...
So, yes, it could be a new attribute "logOnly" as part of the
operationRequestGroup with an answer </received> (just after the
response header). And we could add an attribute "acceptLogRequests"
in the <operations> element in capabilities responses. The other
option would be to include a new operation, but maybe it's better to
just have it as an optional attribute for all operations.
Best Regards,
--
Renato
On 19 Jul 2006 at 10:32, John R. WIECZOREK wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I appreciate that you will consider this request. I always thought
it
would be trivial to implement. Your simulation mode sounds very much
like what I had in mind. I hadn't thought it necessary to get a
response from a log request, but if there was a simple response, it
could be used as a ping, or it could be used to retry logging until
the provider did respond. So, something like <log request received>.
I think the addition oflogOnly attribute is a good one, and could
apply to every request type.
Javi, I don't disagree that portals SHOULD log the data usage,
especially to cover the situations where a provider doesn't respond.
I also think that having the information logged at the provider is a
responsible course of action, since they will have immediate access
to the usage statistics that way. It will be much easier for a
portal
builder to send log requests than it will be to build the
infrastructure and interfaces to logs, therefore it is more likely
to
actually get done.
On 7/18/06, Javier de la Torre <a class="moz-txt-link-rfc2396E"
href="mailto:ja...@mn..."><ja...@mn...></a> wrote:
I am not sure about this,
I still think that portals should be gathering this data and
making
it available for data providers...
But in any case if you like it then I agree with MArkus that the
best
is to include another parameter in the operationRequestGroup.
I havent checked but what happens if you do an extension there
with
an attribute that is implementation specific? A qualified
attribute.
Will this still validate against our schema? You were
discussing
about qualification of attributes before no?
Javi.
On 18/07/2006, at 10:41, Döring, Markus wrote:
> 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="true">
>
>
>
> -- Markus
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: <a class="moz-txt-link-abbreviated"
href="mailto:pyw...@li...">pyw...@li...</a>
>> [<a class="moz-txt-link-freetext"
href="mailto:pyw...@li...">mailto:pyw...@li...</a>] Im
>> Auftrag von John R. WIECZOREK
>> Gesendet: Montag, 17. Juli 2006 23:30
>> An: Renato De Giovanni
>> Cc: <a class="moz-txt-link-abbreviated"
href="mailto:pyw...@li...">pyw...@li...</a>; tdwg-
<a class="moz-txt-link-abbreviated"
href="mailto:ta...@li...">ta...@li...</a>
>> 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 <a
class="moz-txt-link-rfc2396E" href="mailto:re...@cr..."><re...@cr...></a> 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
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
tdwg-tapir mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:tdw...@li...">tdw...@li...</a>
<a class="moz-txt-link-freetext"
href="http://lists.tdwg.org/mailman/listinfo/tdwg-tapir">http://lists.tdwg.org/mailman/listinfo/tdwg-tapir</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
-------------------------------------
Roger Hyam
Technical Architect
Taxonomic Databases Working Group
-------------------------------------
<a class="moz-txt-link-freetext" href="http://www.tdwg.org">http://www.tdwg.org</a>
<a class="moz-txt-link-abbreviated" href="mailto:ro...@td...">ro...@td...</a>
+44 1578 722782
-------------------------------------
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
tdwg-tapir mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tdw...@li...">tdw...@li...</a>
<a class="moz-txt-link-freetext" href="http://lists.tdwg.org/mailman/listinfo/tdwg-tapir">http://lists.tdwg.org/mailman/listinfo/tdwg-tapir</a>
</pre>
</blockquote>
</body>
</html>
|
|
From: Roger H. <ro...@td...> - 2006-07-24 10:53:19
|
I thought this sounded like a good idea but since reading Renato's message I am now confused. If a user does a search on a portal and gets 100 results and looks at the first 10 does the provider of the 11th record get notified? Their data has been used because it has been given in the count. Another example would be if a portal gave a distribution map to 10km squares based in data from multiple providers. Each data point is made from several suppliers data and removal of any one supplier's data may not change the map. Do we notify them all? I could envisage a GUID based system just about. The call to the log function would basically say "Some one has accessed the data that I got from you that you tag with this GUID" but I can't see how this would work on a search based system. The log call would mean "Some one searched for something that made used of data I got from a search I did on you once". So really the only service we need is a GUID based one. Perhaps extending the LSID resolution spec would be more appropriate? Roger Renato De Giovanni wrote: > Hi John, > > Implementing the log request was never a problem. We discussed about > that again during the Madrid meeting, and only after that a feature > freeze was suggested. It's true that PyWrapper is being adjusted now > to conform to the new specs, and considering that DiGIR2 (or wasabi) > postponed implementation of TAPIR, I suppose it should not be a big > problem to make additional changes if necessary. > > The main problem I had with the log request was that it would > probably not solve the issue behind it, which is to track usage by > data aggregators. I still have the same feeling, and I can easily > imagine situations when it would not be easy or even possible to > translate searches on top of cached databases to TAPIR requests. > > But maybe I'm wrong, and if you all think it's a good feature then we > can try to include it. However, I do think that providers should be > able to advertise as the part of capabilities if they want to receive > log requests or not. > > To me it also sounds like a new operation, especially if it's only > related to search. It could make sense for view, inventory and > metadata operations. Maybe capabilities too. But it doesn't make > sense for ping. Well, maybe it could make sense for ping if the data > aggregator monitors provider status and accepts similar requests on > top of its results... > > So, yes, it could be a new attribute "logOnly" as part of the > operationRequestGroup with an answer </received> (just after the > response header). And we could add an attribute "acceptLogRequests" > in the <operations> element in capabilities responses. The other > option would be to include a new operation, but maybe it's better to > just have it as an optional attribute for all operations. > > Best Regards, > -- > Renato > > On 19 Jul 2006 at 10:32, John R. WIECZOREK wrote: > >> I appreciate that you will consider this request. I always thought >> it >> would be trivial to implement. Your simulation mode sounds very much >> like what I had in mind. I hadn't thought it necessary to get a >> response from a log request, but if there was a simple response, it >> could be used as a ping, or it could be used to retry logging until >> the provider did respond. So, something like <log request received>. >> I think the addition oflogOnly attribute is a good one, and could >> apply to every request type. >> >> Javi, I don't disagree that portals SHOULD log the data usage, >> especially to cover the situations where a provider doesn't respond. >> I also think that having the information logged at the provider is a >> responsible course of action, since they will have immediate access >> to the usage statistics that way. It will be much easier for a >> portal >> builder to send log requests than it will be to build the >> infrastructure and interfaces to logs, therefore it is more likely >> to >> actually get done. >> >> >> On 7/18/06, Javier de la Torre <ja...@mn...> wrote: >> I am not sure about this, >> >> I still think that portals should be gathering this data and >> making >> it available for data providers... >> >> But in any case if you like it then I agree with MArkus that the >> best >> is to include another parameter in the operationRequestGroup. >> >> I havent checked but what happens if you do an extension there >> with >> an attribute that is implementation specific? A qualified >> attribute. >> Will this still validate against our schema? You were >> discussing >> about qualification of attributes before no? >> >> Javi. >> >> On 18/07/2006, at 10:41, Döring, Markus wrote: >> >> > 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="true"> >> > >> > >> > >> > -- Markus >> > >> > >> >> -----Ursprüngliche 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...; tdwg- >> ta...@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, >> >> >> >>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 > tdw...@li... > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > > -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org ro...@td... +44 1578 722782 ------------------------------------- |
|
From: Renato De G. <re...@cr...> - 2006-07-19 19:54:37
|
Hi, > Im checking the GET invoked operations now and I cant remember the > reason why we introduced another view request. We should provide > Charles some arguments why it exists and why we didnt just include > template as a parameter in inventories and searches. What was wrong > about that? As I said, the only reason for the view operation was to accommodate TAPIRLite providers. Apparently it was the easiest way to do that. Remeber their requirements: * No need to parse XML requests (only GET requests with simple key/value parameters) * No need to parse filters. * No need to implement "partial". * All queries based on templates. There could be other ways to allow the existence of TAPIRLite without having the view operation, such as including many new attributes in the search operation capabilities, but it would easily get confusing and contradictory, I think. Searches and inventories can make use of templates already, can't they? (at least in XML requests, but I don't see why not via GET requests as well). > - is the envelope turned off or on when non view requests are called > via GET? I thought its turned off then. Am I right? If this is not documented/defined somewhere I would suggest to turn on the envelope by default for all non view requests. > - inventories without envelope need some embracing root element > above > the <record> elements. So should we answer with <tapir:inventory> > ? I understood that turning off envelopes just meant removing header and diagnostics. The root element would still be <response>. > - If so, shouldnt we do the same for the other operations (with > exception of views maybe - well, actually an inventory view has the > same problem!). If we would do so, the summary element for paging is > there as well and we would not need to turn on the entire envelope > for counts. > - if not, what about ping? Same answer above. > Looks like I am discovering ever more little questions. > Stay tuned. No worries, let's kill them all! -- Renato |
|
From: Renato De G. <re...@cr...> - 2006-07-19 18:58:20
|
Hi John, Implementing the log request was never a problem. We discussed about that again during the Madrid meeting, and only after that a feature freeze was suggested. It's true that PyWrapper is being adjusted now to conform to the new specs, and considering that DiGIR2 (or wasabi) postponed implementation of TAPIR, I suppose it should not be a big problem to make additional changes if necessary. The main problem I had with the log request was that it would probably not solve the issue behind it, which is to track usage by data aggregators. I still have the same feeling, and I can easily imagine situations when it would not be easy or even possible to translate searches on top of cached databases to TAPIR requests. But maybe I'm wrong, and if you all think it's a good feature then we can try to include it. However, I do think that providers should be able to advertise as the part of capabilities if they want to receive log requests or not. To me it also sounds like a new operation, especially if it's only related to search. It could make sense for view, inventory and metadata operations. Maybe capabilities too. But it doesn't make sense for ping. Well, maybe it could make sense for ping if the data aggregator monitors provider status and accepts similar requests on top of its results... So, yes, it could be a new attribute "logOnly" as part of the operationRequestGroup with an answer </received> (just after the response header). And we could add an attribute "acceptLogRequests" in the <operations> element in capabilities responses. The other option would be to include a new operation, but maybe it's better to just have it as an optional attribute for all operations. Best Regards, -- Renato On 19 Jul 2006 at 10:32, John R. WIECZOREK wrote: > > I appreciate that you will consider this request. I always thought > it > would be trivial to implement. Your simulation mode sounds very much > like what I had in mind. I hadn't thought it necessary to get a > response from a log request, but if there was a simple response, it > could be used as a ping, or it could be used to retry logging until > the provider did respond. So, something like <log request received>. > I think the addition oflogOnly attribute is a good one, and could > apply to every request type. > > Javi, I don't disagree that portals SHOULD log the data usage, > especially to cover the situations where a provider doesn't respond. > I also think that having the information logged at the provider is a > responsible course of action, since they will have immediate access > to the usage statistics that way. It will be much easier for a > portal > builder to send log requests than it will be to build the > infrastructure and interfaces to logs, therefore it is more likely > to > actually get done. > > > On 7/18/06, Javier de la Torre <ja...@mn...> wrote: > I am not sure about this, > > I still think that portals should be gathering this data and > making > it available for data providers... > > But in any case if you like it then I agree with MArkus that the > best > is to include another parameter in the operationRequestGroup. > > I havent checked but what happens if you do an extension there > with > an attribute that is implementation specific? A qualified > attribute. > Will this still validate against our schema? You were > discussing > 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 > > 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 > > > > > >> -----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...; tdwg- > ta...@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, > >> > >>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=F6ring, 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 |
|
From: John R. W. <tu...@be...> - 2006-07-19 17:32:40
|
I appreciate that you will consider this request. I always thought it would be trivial to implement. Your simulation mode sounds very much like what I had in mind. I hadn't thought it necessary to get a response from a log request, but if there was a simple response, it could be used as a ping, or it could be used to retry logging until the provider did respond. So, something like <log request received>. I think the addition of logOnly attribute is a good one, and could apply to every request type. Javi, I don't disagree that portals SHOULD log the data usage, especially t= o cover the situations where a provider doesn't respond. I also think that having the information logged at the provider is a responsible course of action, since they will have immediate access to the usage statistics that way. It will be much easier for a portal builder to send log requests than it will be to build the infrastructure and interfaces to logs, therefore it is more likely to actually get done. On 7/18/06, Javier de la Torre <ja...@mn...> wrote: > > I am not sure about this, > > I still think that portals should be gathering this data and making > it available for data providers... > > But in any case if you like it then I agree with MArkus that the best > is to include another parameter in the operationRequestGroup. > > I havent checked but what happens if you do an extension there with > an attribute that is implementation specific? A qualified attribute. > Will this still validate against our schema? You were discussing > 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 > > 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 > > > > > >> -----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, > >> > >> 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=F6ring, 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 > >> tdw...@li... > >> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > >> <http://lists.tdwg.org/mailman/listinfo/tdwg-tapir> > >> > >> > >> > >> > > _______________________________________________ > > tdwg-tapir mailing list > > tdw...@li... > > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > > |
|
From: Renato De G. <re...@cr...> - 2006-07-19 16:13:29
|
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=F6ring, 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=FCngliche Nachricht----- > > Von: pyw...@li... > > [mailto:pyw...@li...] Im > > Auftrag von Renato De Giovanni > > Gesendet: Montag, 17. Juli 2006 23:01 > > An: tdw...@li... > > Cc: pyw...@li... > > 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=F6ring, 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 |
|
From: <m.d...@BG...> - 2006-07-19 09:07:02
|
So you are suggesting that the formerly global parameter "envelope" is = only allowed in searches or views based on search templates but not on = inventories? Thats a change too: http://ww3.bgbm.org/protocolwiki/GetInvokedOperations We really need to update this page to have a definite reference. Views = are missing entirely. I was collecting some changes on the wiki so charles doesnt forget to = include them in the specs. its really not finished and already outdated, = but we need it documented somewhere. Please feel free to edit it = continously! http://ww3.bgbm.org/protocolwiki/ImplementationAndDocumentationChanges -- Markus =20 > -----Urspr=FCngliche Nachricht----- > Von: pyw...@li...=20 > [mailto:pyw...@li...] Im=20 > Auftrag von Javier de la Torre > Gesendet: Mittwoch, 19. Juli 2006 10:30 > An: Markus D=F6ring > Cc: Renato de Giovanni;=20 > pyw...@li...; D=F6ring, Markus > Betreff: Re: [PyWrapper-devel] tapir get requests & views >=20 > Hi Markus, >=20 > I leave some questions open. >=20 > > - is the envelope turned off or on when non view requests=20 > are called=20 > > via GET? I thought its turned off then. Am I right? >=20 > Uff... I would expect it to be turn on, this is the TAPIR=20 > protocol and therefore we should use our envelope unless the=20 > user says no. >=20 > > - inventories without envelope need some embracing root=20 > element above=20 > > the <record> elements. So should we answer with <tapir:inventory> ? > This is because we didnt think on inventories without=20 > envelope. If we have to invent an embracing element then I=20 > prefer to have the proper envelope. > Inventories are a very TAPIR thing. I have the impression=20 > that what you actually want is to have inventories as an=20 > specific search with a select distinct operator. What is=20 > actually fine for me, but I would not make such change now. >=20 > > - If so, shouldnt we do the same for the other operations (with=20 > > exception of views maybe - well, actually an inventory view has the=20 > > same problem!). If we would do so, the summary element for=20 > paging is=20 > > there as well and we would not need to turn on the entire=20 > envelope for=20 > > counts. >=20 > Does it matter to have a half envelope or a full envelope? I=20 > think I rather stay with an envelope. >=20 > > - if not, what about ping? > pong. >=20 >=20 >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV > _______________________________________________ > PyWrapper-devel mailing list > PyW...@li... > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel >=20 |
|
From: Javier de la T. <ja...@mn...> - 2006-07-19 08:30:22
|
Hi Markus, I leave some questions open. > - is the envelope turned off or on when non view requests are > called via GET? I thought its turned off then. Am I right? Uff... I would expect it to be turn on, this is the TAPIR protocol and therefore we should use our envelope unless the user says no. > - inventories without envelope need some embracing root element > above the <record> elements. So should we answer with > <tapir:inventory> ? This is because we didnt think on inventories without envelope. If we have to invent an embracing element then I prefer to have the proper envelope. Inventories are a very TAPIR thing. I have the impression that what you actually want is to have inventories as an specific search with a select distinct operator. What is actually fine for me, but I would not make such change now. > - If so, shouldnt we do the same for the other operations (with > exception of views maybe - well, actually an inventory view has the > same problem!). If we would do so, the summary element for paging > is there as well and we would not need to turn on the entire > envelope for counts. Does it matter to have a half envelope or a full envelope? I think I rather stay with an envelope. > - if not, what about ping? pong. |
|
From: <wi...@go...> - 2006-07-18 22:49:41
|
me again. Im checking the GET invoked operations now and I cant remember the reason why we introduced another view request. We should provide Charles some arguments why it exists and why we didnt just include template as a parameter in inventories and searches. What was wrong about that? and some more detailed questions: - is the envelope turned off or on when non view requests are called via GET? I thought its turned off then. Am I right? - inventories without envelope need some embracing root element above the <record> elements. So should we answer with <tapir:inventory> ? - If so, shouldnt we do the same for the other operations (with exception of views maybe - well, actually an inventory view has the same problem!). If we would do so, the summary element for paging is there as well and we would not need to turn on the entire envelope for counts. - if not, what about ping? Looks like I am discovering ever more little questions. Stay tuned. Markus |
|
From: Javier de la T. <ja...@mn...> - 2006-07-18 11:35:18
|
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 |
|
From: <m.d...@BG...> - 2006-07-18 08:41:07
|
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 |
|
From: <m.d...@BG...> - 2006-07-18 08:32:16
|
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.=20 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 =20 > -----Urspr=FCngliche Nachricht----- > Von: pyw...@li...=20 > [mailto:pyw...@li...] Im=20 > Auftrag von Renato De Giovanni > Gesendet: Montag, 17. Juli 2006 23:01 > An: tdw...@li... > Cc: pyw...@li... > Betreff: Re: [PyWrapper-devel] WG: tapir: capabilities >=20 > Hi, >=20 > If I remember well, the "view" operation was re-included in=20 > the protocol just to handle query templates, especifically=20 > for TapirLite providers. So if someone wants to query a=20 > provider using some external output model that should be=20 > dynamically parsed, then the "search" operation must be used=20 > instead (using either XML or simple GET request). View=20 > operations are really bound to query templates, and they are=20 > not allowed to specify "filter" or "partial" parameters. > -- > Renato >=20 > On 17 Jul 2006 at 21:26, "D=F6ring, Markus" wrote: >=20 > > I was just about to edit the schema and realizing that=20 > output models=20 > > are only specified for searches. but what about views? they=20 > use query=20 > > templates, yes. but only the ones listed in capabilities? we should=20 > > have dynamic ones here as well I think. And they link back to=20 > > static/dynamic models. > >=20 > > So should models maybe become a seperate section not tight to=20 > > search/view operations? I am going to modify the schema=20 > nevertheless=20 > > already to accomodate the changes below - ignoring views for now. > >=20 > > Markus >=20 >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV > _______________________________________________ > PyWrapper-devel mailing list > PyW...@li... > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel >=20 |
|
From: John R. W. <tu...@be...> - 2006-07-17 21:30:28
|
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 i= n 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, > > 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=F6ring, 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 > tdw...@li... > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir > |
7 messages has been excluded from this view by a project administrator.
