Roger, actually the caller knows exactly the filter, cause he knows the URL pointing to the template defining the parameters. And there he can easily check what kind of operator it is - unary,binary, unbounded.

Markus

-----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Roger Hyam Gesendet: Freitag, 2. Dezember 2005 16:36 An: Döring, Markus Cc: tdwg-tapir@lists.tdwg.org Betreff: Re: [tdwg-tapir] TaxonAPI

Hi Markus,

I can see that but what I don't get is how "id=tr123672&id=df678923&id=jk8912494" maps into the filter.

If the filter contains a " WHERE x IN (id) " then it would be quite easy to see what to do with multiple values but if the filter contained a "WHERE x = id" then I what should the implementation do? Throw an error I guess.

The caller would have to know that a parameter of a filter could be multi valued or not. I suppose this is fine because the caller has to know other stuff as well.

Roger

Döring, Markus wrote:

Roger, I dont think there is a problem in pasing multiple values for the same parameter name. Like for multi select boxes in html you can pass the same parameter several times with different value. Et voila, the IN operator has several arguments.

For example: http://short.com/TapirLite.cgi?op=search&id=tr123672&id=df678923&... 8912494

markus

-----Ursprüngliche Nachricht----- Von: Roger Hyam [mailto:roger@tdwg.org] Gesendet: Donnerstag, 1. Dezember 2005 15:11 An: Döring, Markus Cc: Renato De Giovanni; tdwg-tapir@lists.tdwg.org Betreff: Re: [tdwg-tapir] TaxonAPI

The place where we need to pass the array of string is in passing a set of IDs to retrieve multiple objects so there is no need for a likeAny operator I don't think. An In operator does the job. What is difficult is how we pass in the values in a URL. Perhaps there should be a requirement for multiple occurrences of the same parameter to be concatenated together in some useful ways - to build and IN.

Parameters other than the IDs for these calls are just ANDed together.

When I stipulates the passing of an array like that it was because I envisaged a client crawling a resource. The client would typically retrieve an object (or objects) then want to get a set of related objects. Being able to pass a list saves making multiple calls.

It may be kinder to the publisher to only get one object by id at a time. It would be easier to implement and would entail less work per call but more calls.

Simplicity would dictate change the API not to have arrays like this.

I'll have a think about it next time I look at the API. It may be easier to change the API than Tapir but I am not clear how one would pass a list of parameters to a Tapir IN at the moment anyhow.

Roger

Döring, Markus wrote:

Renato & Roger, would it make sense to have a new unbound "likeAny" operator that works like an IN but does a like instead of an equals behind the scenes?

Then you could just pass an array of string arguments for like or equal comparisons just with the same GET paramter name. E.g. TapirLite.cgi?op=search&name=Abies*&name=Pinus*&name=Picea*

Markus

-----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Renato De Giovanni Gesendet: Mittwoch, 30. November 2005 17:54 An: tdwg-tapir@lists.tdwg.org Betreff: Re: [tdwg-tapir] TaxonAPI

Hi Roger,

I looked at the API and apparently it seems to be consistent with the TapirLite idea, although there are still lots of things that I still need to learn about the TCS world.

The only thing is that you frequently define parameter types as "Array of Strings", and we don't have that notion in the protocol. As far as I know, the only way to do this with the current parameterised Tapir filters is to limit the parameter to a single string value (and then make several requests), or define a filter with several conditions referencing different string parameters (like name1, name2, etc) all joined by ORs.

Another possibility would be to change the "in" operator and make it accept not only literal values but also a parameter that could be expanded according to the number of associated values. It looks more elegant but needs a small change in the protocol (and additional notes in the specification).

Regards,

Renato

On 28 Nov 2005 at 10:54, Roger Hyam wrote:

Hi Everyone,

I have been doing some work on a TaxonAPI. This is a high/low definition of the kind of thing I believe people publishing taxonomic data need to produce and people consuming it need to eat based on the work I have been involved in on TCS. It is framed as if it were a web service type of thing but I imagine that each of the method calls mentioned could equate to a Tapir template of some kind. I imagine a template containing a parameterized filter (not sure if those exist anymore). This is still work in progress as I need to define the list of parameters more closely and sort the greater than/less than issue for dates and a few other bits. Plus no one has seen it to comment on! You can read more about it here: http://www.tdwg.hyam.net/twiki/bin/view/TIP/TaxonAPI I would be most grateful for your comments. How does this fit with Tapir? Roger

---

tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org

---

tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org