<!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">
Renato,<br>
<br>
Thanks. I am glad you like the stuff I put up. It is just pulling
together what a bunch of us have been talking about. The suggestions
you make for capabilities seem good. If I understand the what you are
saying about the filtering then when interpreting a filter that looked
like this:<br>
<br>
<and><br>
<like><br>
<concept
path="/Dataset/TaxonNames/TaxonName/CanonicalName/Genus"/><br>
<parameter name="GenusName"/><br>
</like><br>
<like><br>
<concept
path="/Dataset/TaxonNames/TaxonName/ProviderSpecific/XYZ/Modified"/><br>
<parameter name="ChangedSince" optional="true" /><br>
</like><br>
</and><br>
<br>
and the ChangeSince parameter is not supplied then the second
<like> is ignored. If this is correct then it would be fine.<br>
<br>
If you guys could thrash out the details of these things at the
November meeting that would be great. I'll try and spend a little time
exploring the whole TapirLite area over the next couple of weeks (if I
get a chance) and add any other thoughts.<br>
<br>
Many thanks,<br>
<br>
Roger<br>
<br>
<br>
<br>
Renato De Giovanni wrote:
<blockquote cite="mid4357AE97.2303.1493C7C@localhost" type="cite">
<pre wrap="">Hi Roger,
No need to be nervous, tapirs are friendly animals... ;-)
I really like the idea of TapirLite.
Originally the capibilities response had a specific section to
indicate the supported operations. I think we could bring it back,
making ping, metadata, and capabilities the only mandatory
operations, as suggested. For consistency, perhaps we could make the
accepted views subelements of the corresponding operation element.
And since dynamic views can actually be represented by the
functionality of the search operation, they would become optional.
So for TapirLite implementations, that section could look like:
<operations>
<ping/>
<metadata/>
<capabilities/>
<view>
<view identifier=<a class="moz-txt-link-rfc2396E" href="http://tdwg.org/tapir/views/a"><font color="red"><b>MailScanner has detected a possible fraud attempt from "tdwg.org" claiming to be</b></font> "http://tdwg.org/tapir/views/a"</a> alias="a"/>
<view identifier=<a class="moz-txt-link-rfc2396E" href="http://tdwg.org/tapir/views/b"><font color="red"><b>MailScanner has detected a possible fraud attempt from "tdwg.org" claiming to be</b></font> "http://tdwg.org/tapir/views/b"</a> alias="b"/>
</view>
</operations>
I also like the idea of only using view ids: GUIDs redirecting to the
respective xml definitions. The alias would be the view name used in
URLs.
About filtering, I think it's already possible to have an empty
section "operators" in the capabilities response. And when a
TapirLite provider says it understands a particular view, even if
that view contains an XML-encoded filter the provider could hard code
the local translation for that filter and not necessarily be able to
parse generic filters.
Regarding the new "id-defined" operator, I was thinking if there's
another way to achieve the same results. Perhaps by creating an
additional attribute in the <parameter> element called "optional".
"Optional" could also be optional, and when not specified the
parameter would be considered mandatory. An explicit optional="true"
combined with the inexistence of the parameter could have the effect
of telling the parser to ignore that condition. Just another idea...
Best Regards,
--
Renato
On 20 Oct 2005 at 11:41, Roger Hyam wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Everyone,
I am nervous at being the first to post to this most esteemed list but
here goes.
I have just added two pages to the wiki concerning minor changes that
could be made to the protocol to make it easier to implement 'Lite'
versions of Tapir providers.
<a class="moz-txt-link-freetext" href="http://ww3.bgbm.org/protocolwiki/TapirLite">http://ww3.bgbm.org/protocolwiki/TapirLite</a>
<a class="moz-txt-link-freetext" href="http://ww3.bgbm.org/protocolwiki/SimpleFiltering">http://ww3.bgbm.org/protocolwiki/SimpleFiltering</a>
Please read and add your support or reservations to the wiki or
discuss it here.
All the best,
Roger
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
tdwg-tapir mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tdwg-tapir@lists.tdwg.org">tdwg-tapir@lists.tdwg.org</a>
<a class="moz-txt-link-freetext" href="http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org">http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org</a>
</pre>
</blockquote>
<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:roger@tdwg.org">roger@tdwg.org</a>
+44 1578 722782
-------------------------------------
</pre>
</body>
</html>