[tdwg-tapir] TapirLite and SimpleFiltering pages
Hi Roger & Renato, I somehow wasn't subscribed to the list properly, so I nearly repeated all of Renatos comments on the wiki without being aware of this mail ... I think we said earlier that all parameters in views should be optional by nature - this is also how the pywrapper implements it. Does it make sense for any view to have mandatory parameters in filters? If a parameter is not being used in the actual view call, then this part of the filter should be ignored. Otherwise it would evaluate to false and therefore no AND combinations of parameters would be possible. But if we have a view exposing only one parameter, lets say the objectID, and this one is not given - that also doesnt make too much sense. So this could be a case where a parameter is required.
From the formal aspect I support Renatos idea of having another flag "optional" or "required" to indicate this. We could also use an attribute "use='required'" as in attribute definitions in xml schema. By default I think all parameters should be optional.
Most of the changes are included now in the current schema proposal, but views are still a separate category in capabilities. I dont mind to change this the way renato showed below. One other issue to discuss is importing/including directives in views and schemas. Would it be of great value to have includes in views? If so, would we need include directives on the base of the protocol: <include href="dwc_base.xml"> or should we define xml processing instructions like this: <?include href="dwc_base.xml" ?> If we want to be able to do includes at any place in a document, I think we have to go for PIs. Just something to think about if you are bored. But my main concern is still the IndexingElementExplosion: http://ww3.bgbm.org/protocolwiki/IndexingElementExplosion I hope to have some new ideas about the explosion in my next mail. Thanks, Markus ---------------------------------------- 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="http://tdwg.org/tapir/views/a" alias="a"/> <view identifier="http://tdwg.org/tapir/views/b" 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:
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.
http://ww3.bgbm.org/protocolwiki/TapirLite http://ww3.bgbm.org/protocolwiki/SimpleFiltering
Please read and add your support or reservations to the wiki or discuss it here.
All the best,
Roger
Hello Markus, Some quick comments about the three topics: 1- Filter parameters: I do remember we have discussed about that before, but somehow I had the impression that we didn't come to any concrete conclusion (and if we did, I think that's something we left out of the integration document, so, I'm sorry if I forgot about this detail...). Anyway, I definitely agree that it would be better if we could have it formalized as an attribute. 2- Include directives Not sure if there'll be significant benefits here, but if someone could give an interesting example of such functionality, maybe we can consider it. 3- "IndexingElementExplosion" I already included a comment in the wiki. I really think that's a "non-problem"... Best Regards, -- Renato On 21 Oct 2005 at 19:40, Döring, Markus wrote:
Hi Roger & Renato, I somehow wasn't subscribed to the list properly, so I nearly repeated all of Renatos comments on the wiki without being aware of this mail ...
I think we said earlier that all parameters in views should be optional by nature - this is also how the pywrapper implements it. Does it make sense for any view to have mandatory parameters in filters? If a parameter is not being used in the actual view call, then this part of the filter should be ignored. Otherwise it would evaluate to false and therefore no AND combinations of parameters would be possible. But if we have a view exposing only one parameter, lets say the objectID, and this one is not given - that also doesnt make too much sense. So this could be a case where a parameter is required. >From the formal aspect I support Renatos idea of having another flag "optional" or "required" to indicate this. We could also use an attribute "use='required'" as in attribute definitions in xml schema. By default I think all parameters should be optional.
Most of the changes are included now in the current schema proposal, but views are still a separate category in capabilities. I dont mind to change this the way renato showed below.
One other issue to discuss is importing/including directives in views and schemas. Would it be of great value to have includes in views?
If so, would we need include directives on the base of the protocol: <include href="dwc_base.xml"> or should we define xml processing instructions like this: <?include href="dwc_base.xml" ?> If we want to be able to do includes at any place in a document, I think we have to go for PIs. Just something to think about if you are bored.
But my main concern is still the IndexingElementExplosion: http://ww3.bgbm.org/protocolwiki/IndexingElementExplosion I hope to have some new ideas about the explosion in my next mail.
Thanks, Markus
Include mechanisms: Does having views referred to by URL remove the problem of having some form of include mechanism actually in the view. The file that is retrieved from the URL can be created by whatever dynamic means is most useful - could be XSLT or even old fashioned server side includes. No single view is likely to get so large it is worth dicing up is it? Perhaps this is something that could be push forward into a future version? Renato De Giovanni wrote:
Hello Markus,
Some quick comments about the three topics:
1- Filter parameters:
I do remember we have discussed about that before, but somehow I had the impression that we didn't come to any concrete conclusion (and if we did, I think that's something we left out of the integration document, so, I'm sorry if I forgot about this detail...). Anyway, I definitely agree that it would be better if we could have it formalized as an attribute.
2- Include directives
Not sure if there'll be significant benefits here, but if someone could give an interesting example of such functionality, maybe we can consider it.
3- "IndexingElementExplosion"
I already included a comment in the wiki. I really think that's a "non-problem"...
Best Regards, -- Renato
On 21 Oct 2005 at 19:40, Döring, Markus wrote:
Hi Roger & Renato, I somehow wasn't subscribed to the list properly, so I nearly repeated all of Renatos comments on the wiki without being aware of this mail ...
I think we said earlier that all parameters in views should be optional by nature - this is also how the pywrapper implements it. Does it make sense for any view to have mandatory parameters in filters? If a parameter is not being used in the actual view call, then this part of the filter should be ignored. Otherwise it would evaluate to false and therefore no AND combinations of parameters would be possible. But if we have a view exposing only one parameter, lets say the objectID, and this one is not given - that also doesnt make too much sense. So this could be a case where a parameter is required. >From the formal aspect I support Renatos idea of having another flag "optional" or "required" to indicate this. We could also use an attribute "use='required'" as in attribute definitions in xml schema. By default I think all parameters should be optional.
Most of the changes are included now in the current schema proposal, but views are still a separate category in capabilities. I dont mind to change this the way renato showed below.
One other issue to discuss is importing/including directives in views and schemas. Would it be of great value to have includes in views?
If so, would we need include directives on the base of the protocol: <include href="dwc_base.xml"> or should we define xml processing instructions like this: <?include href="dwc_base.xml" ?> If we want to be able to do includes at any place in a document, I think we have to go for PIs. Just something to think about if you are bored.
But my main concern is still the IndexingElementExplosion: http://ww3.bgbm.org/protocolwiki/IndexingElementExplosion I hope to have some new ideas about the explosion in my next mail.
Thanks, Markus
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
-- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger@tdwg.org +44 1578 722782 -------------------------------------
Dear all, Samy Gaiji, from IPGRI, sent us yesterday an email with comments about TAPIR. He consider the response format of the inventory operation inconvenient. For those not remembering an inventory operation looks like this: Request: ------------ <?xml version='1.0' encoding='UTF-8'?> <request> <header /> <inventory count='true' start='0' limit='50' xmlns:dwc='http://digir.net/schema/conceptual/darwin/2003/1.0'> <concepts> <concept path='dwc:/Country' /> <concept path='dwc:/Genus' /> </concepts> </inventory> </request> ---- Response ------------- <?xml version="1.0" encoding="UTF-8"?> <response> <header></header> <inventory> <record> <value>AUSTRALIA</value> <value>Calicium</Genus> </record> <summary start="0" totalReturned="50" totalMatched="73" next="50" /> </inventory> </response> -------------- He find hards to parse after that all concepts are named 'value' and having to trust on that the elements are returned in the same order as they were request. I don't know, for me this does not look like a big issue, but in any case here is a proposal that makes possible to assign names to the elements that are responded. Request: ----------------------------------- <?xml version='1.0' encoding='UTF-8'?> <request> <header /> <inventory count='true' start='0' limit='50' xmlns:dwc='http://digir.net/schema/conceptual/darwin/2003/1.0'> <concepts> <concept path='dwc:/Country' elementName='Country' /> <concept path='dwc:/Genus' elementName='Genus' /> </concepts> </inventory> </request> ------------------------------- Response: ------------------------------- <?xml version="1.0" encoding="UTF-8"?> <response> <header></header> <inventory> <record> <Country>AUSTRALIA</Country> <Genus>Calicium</Genus> </record> <summary start="0" totalReturned="50" totalMatched="73" next="50" /> </inventory> </response> ------------------------ You can find attached a modification of the latest protocol schema that includes this. What are your thoughts on this? Best regards, Javier.
I have no problem with this - something along these lines seems sensible. Donald --------------------------------------------------------------- Donald Hobern (dhobern@gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 --------------------------------------------------------------- -----Original Message----- From: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] On Behalf Of Javier de la Torre Sent: 25 October 2005 12:41 To: tdwg-tapir@lists.tdwg.org Subject: [tdwg-tapir] {Definitely Spam?} Modification in the Inventoryresponse Dear all, Samy Gaiji, from IPGRI, sent us yesterday an email with comments about TAPIR. He consider the response format of the inventory operation inconvenient. For those not remembering an inventory operation looks like this: Request: ------------ <?xml version='1.0' encoding='UTF-8'?> <request> <header /> <inventory count='true' start='0' limit='50' xmlns:dwc='http://digir.net/schema/conceptual/darwin/2003/1.0'> <concepts> <concept path='dwc:/Country' /> <concept path='dwc:/Genus' /> </concepts> </inventory> </request> ---- Response ------------- <?xml version="1.0" encoding="UTF-8"?> <response> <header></header> <inventory> <record> <value>AUSTRALIA</value> <value>Calicium</Genus> </record> <summary start="0" totalReturned="50" totalMatched="73" next="50" /> </inventory> </response> -------------- He find hards to parse after that all concepts are named 'value' and having to trust on that the elements are returned in the same order as they were request. I don't know, for me this does not look like a big issue, but in any case here is a proposal that makes possible to assign names to the elements that are responded. Request: ----------------------------------- <?xml version='1.0' encoding='UTF-8'?> <request> <header /> <inventory count='true' start='0' limit='50' xmlns:dwc='http://digir.net/schema/conceptual/darwin/2003/1.0'> <concepts> <concept path='dwc:/Country' elementName='Country' /> <concept path='dwc:/Genus' elementName='Genus' /> </concepts> </inventory> </request> ------------------------------- Response: ------------------------------- <?xml version="1.0" encoding="UTF-8"?> <response> <header></header> <inventory> <record> <Country>AUSTRALIA</Country> <Genus>Calicium</Genus> </record> <summary start="0" totalReturned="50" totalMatched="73" next="50" /> </inventory> </response> ------------------------ You can find attached a modification of the latest protocol schema that includes this. What are your thoughts on this?
participants (5)
-
"Döring, Markus" -
Donald Hobern -
Javier de la Torre -
Renato De Giovanni -
Roger Hyam