pywrapper-devel — PyWrapper Developers mailing list

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

[Renato De G. <re...@cr...>]

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

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

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

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


-----Original Message-----
From:	Javier privat
Sent:	Mon 7/17/2006 4:00 PM
To:	D=F6ring, Markus
Cc:	Copp, Charles; Renato De Giovanni; =
pyw...@li...; tdw...@li...
Subject:	Re: WG: tapir: capabilities

I suppose is fine yes...
It is also easier to explain dynamic/static :)

Javi.

On 7/17/06, "D=F6ring, Markus" <m.d...@bg...> wrote:
> Renato,
> I agree with your remarks. And I think we should stress the =
dynamic/static meaning more than the standard/custom one.
>
> If everyone agrees I would opt for the dynamic/static terminology then =
and modify the capabilities section as renato has outlined?. Especially =
as we have been refering to dynamic models ever since.
>
> -- Markus
>
>
> > -----Urspr=FCngliche Nachricht-----
> > Von: Copp, Charles
> > Gesendet: Montag, 17. Juli 2006 15:29
> > An: Renato De Giovanni
> > Cc: D=F6ring, Markus; Javier privat
> > Betreff: Re: WG: tapir: capabilities
> >
> > I think - standard/custom or static/dynamic is a choice of
> > terms that either would suit depending on how you want to
> > emphasise what they do.
> >
> > standard - meaning it comes provided for you as part of the
> > service you are contacting and custom means that it can be
> > changed and the user declares it.  static/dynamic emphasise
> > what the service is doing in processing terms.
> >
> > I think your Renato's comment on <structure> makes sense.
> >
> > Charles
> >
> >
> >
>
> Hi,
>
> I think I'm fine with any of the options. It could be "standard" if =
you all liked. The only detail is that a standardOutputModel doesn't =
necessarily come from an external library of standard models. It can =
also be something specifically tailored by the data provider for some =
reason.
>
> By the way, I'm looking at the schema now and it seems to be possible =
to have a "customOutputModels" element with attribute "accepted=3Dtrue"
> but with no schema structure capabilities specified - which is =
inconsistent.
>
> I think that the "customOutputModels" section is more related to the =
ability to dynamically process any output model specified in requests. =
In contrast, the "predefinedOutputModels" is just a list of "static" =
output models that are understood by the provider, regardless of having =
the response schema structure processed dynamically or not.
>
> So another possibility would be:
>
> <staticOutputModels>
>  ...list of outputModels...
> </staticOutputModels>
> <dynamicOutputModels>
>   <structure>...</structure>
> <dynamicOutputModels>
>
> In this case <structure> could become mandatory (minOccurs=3D1) and we =
could remove the attribute "accepted".
> Just another idea...
> --
> Renato
>
>
> On 17 Jul 2006 at 13:20, "D=F6ring, Markus" wrote:
>
> > hi,
> > a name for "predefined" model.
> > charles suggests "standard" as oppoased to custom.
> > I think that hits the nail on the head.
> >
> > other suggestions so far:
> > - standard
> > - shared
> > - preconfigured
> > - known
> > - available
> >
> >
> > lets pick!
> >
> >
> > -- Markus
> >
>

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

[Javier de la T. <ja...@gm...>]

I suppose is fine yes...
It is also easier to explain dynamic/static :)

Javi.

On 7/17/06, "D=F6ring, Markus" <m.d...@bg...> wrote:
> Renato,
> I agree with your remarks. And I think we should stress the dynamic/stati=
c meaning more than the standard/custom one.
>
> If everyone agrees I would opt for the dynamic/static terminology then an=
d modify the capabilities section as renato has outlined?. Especially as we=
 have been refering to dynamic models ever since.
>
> -- Markus
>
>
> > -----Urspr=FCngliche Nachricht-----
> > Von: Copp, Charles
> > Gesendet: Montag, 17. Juli 2006 15:29
> > An: Renato De Giovanni
> > Cc: D=F6ring, Markus; Javier privat
> > Betreff: Re: WG: tapir: capabilities
> >
> > I think - standard/custom or static/dynamic is a choice of
> > terms that either would suit depending on how you want to
> > emphasise what they do.
> >
> > standard - meaning it comes provided for you as part of the
> > service you are contacting and custom means that it can be
> > changed and the user declares it.  static/dynamic emphasise
> > what the service is doing in processing terms.
> >
> > I think your Renato's comment on <structure> makes sense.
> >
> > Charles
> >
> >
> >
>
> Hi,
>
> I think I'm fine with any of the options. It could be "standard" if you a=
ll liked. The only detail is that a standardOutputModel doesn't necessarily=
 come from an external library of standard models. It can also be something=
 specifically tailored by the data provider for some reason.
>
> By the way, I'm looking at the schema now and it seems to be possible to =
have a "customOutputModels" element with attribute "accepted=3Dtrue"
> but with no schema structure capabilities specified - which is inconsiste=
nt.
>
> I think that the "customOutputModels" section is more related to the abil=
ity to dynamically process any output model specified in requests. In contr=
ast, the "predefinedOutputModels" is just a list of "static" output models =
that are understood by the provider, regardless of having the response sche=
ma structure processed dynamically or not.
>
> So another possibility would be:
>
> <staticOutputModels>
>  ...list of outputModels...
> </staticOutputModels>
> <dynamicOutputModels>
>   <structure>...</structure>
> <dynamicOutputModels>
>
> In this case <structure> could become mandatory (minOccurs=3D1) and we co=
uld remove the attribute "accepted".
> Just another idea...
> --
> Renato
>
>
> On 17 Jul 2006 at 13:20, "D=F6ring, Markus" wrote:
>
> > hi,
> > a name for "predefined" model.
> > charles suggests "standard" as oppoased to custom.
> > I think that hits the nail on the head.
> >
> > other suggestions so far:
> > - standard
> > - shared
> > - preconfigured
> > - known
> > - available
> >
> >
> > lets pick!
> >
> >
> > -- Markus
> >
>

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

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

Renato,
I agree with your remarks. And I think we should stress the =
dynamic/static meaning more than the standard/custom one.

If everyone agrees I would opt for the dynamic/static terminology then =
and modify the capabilities section as renato has outlined?. Especially =
as we have been refering to dynamic models ever since.=20

-- Markus
 =20

> -----Urspr=FCngliche Nachricht-----
> Von: Copp, Charles=20
> Gesendet: Montag, 17. Juli 2006 15:29
> An: Renato De Giovanni
> Cc: D=F6ring, Markus; Javier privat
> Betreff: Re: WG: tapir: capabilities
>=20
> I think - standard/custom or static/dynamic is a choice of=20
> terms that either would suit depending on how you want to=20
> emphasise what they do.
>=20
> standard - meaning it comes provided for you as part of the=20
> service you are contacting and custom means that it can be=20
> changed and the user declares it.  static/dynamic emphasise=20
> what the service is doing in processing terms.
>=20
> I think your Renato's comment on <structure> makes sense.
>=20
> Charles
>=20
>=20
>=20

Hi,

I think I'm fine with any of the options. It could be "standard" if you =
all liked. The only detail is that a standardOutputModel doesn't =
necessarily come from an external library of standard models. It can =
also be something specifically tailored by the data provider for some =
reason.

By the way, I'm looking at the schema now and it seems to be possible to =
have a "customOutputModels" element with attribute "accepted=3Dtrue"=20
but with no schema structure capabilities specified - which is =
inconsistent.

I think that the "customOutputModels" section is more related to the =
ability to dynamically process any output model specified in requests. =
In contrast, the "predefinedOutputModels" is just a list of "static" =
output models that are understood by the provider, regardless of having =
the response schema structure processed dynamically or not.

So another possibility would be:

<staticOutputModels>
 ...list of outputModels...
</staticOutputModels>
<dynamicOutputModels>
  <structure>...</structure>
<dynamicOutputModels>

In this case <structure> could become mandatory (minOccurs=3D1) and we =
could remove the attribute "accepted".=20
Just another idea...
--
Renato


On 17 Jul 2006 at 13:20, "D=F6ring, Markus" wrote:

> hi,
> a name for "predefined" model.
> charles suggests "standard" as oppoased to custom.
> I think that hits the nail on the head.
>=20
> other suggestions so far:
> - standard
> - shared
> - preconfigured
> - known
> - available
>=20
>=20
> lets pick!
>=20
>=20
> -- Markus
> =20

[PyWrapper-devel] WG: tapir: capabilities

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

hi,
a name for "predefined" model.
charles suggests "standard" as oppoased to custom.
I think that hits the nail on the head.

other suggestions so far:
- standard
- shared
- preconfigured
- known
- available


lets pick!


-- Markus
=20
-----Urspr=FCngliche Nachricht-----
Von: Copp, Charles=20
Gesendet: Montag, 17. Juli 2006 11:41
An: D=F6ring, Markus
Betreff: Re: tapir: capabilities

Hi Markus
sorry for further delays - I never got a thing written last week. I had =
to set up a new sever system here because I needed to move to a full SQL =
Server to handle the thesaurus database and Luxembourg Museums database =
- also it was too hot to think.  Back in business now.

I have already been using Required in the documentation so thats fine.

With the output model - What about standardOuputModel  as opposed to =
customOutputModels

Charles

[PyWrapper-devel] text encodings

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

Hi,
when looking at the A9 specification I saw they introduced a parameter =
to specify input and output encoding. At first I thought we dont need =
that cause we got the XML character encoding, but what about our GET =
calls? I dont really like the idea to specify the encoding, but I would =
love to dictate that its gotta be UTF-8.

What do you think?
http://opensearch.a9.com/spec/1.1/querysyntax/#optionalrequired

-- Markus
=20

Re: [PyWrapper-devel] view operation issues and others

[<wi...@go...>]

Renato, Javier,
I think we agree with most issues I raised. See comments below.
I copied the mail to the developer list cause Renato is right, this  
makes good documentation for others.
cheers,
Markus


>
> On 14.07.2006, at 03:22, Renato De Giovanni wrote:
>
> Hi Markus,
>
>> the pywrapper gets closer to the specs!
>
> Exciting stuff!
>
>> Im finishing the view implementation and got the following questions
>> - not sure if we tackled them yet:
>
> BTW, these are typical questions that only pop up during  
> implementation...
> And it's also the kind of conversation that we could make use of our
> mailing list, I think. Maybe other people could help defining these
> things.
>
> (oh, and Charles should also know about the final decisions.)
>
>> 1) Default response is with envelope turned off. What happens in case
>> of serious errors?
>>     - simple respond <Error>
>>     - turn on the envelope and response with response/error
>
> That's tricky. I kind of dislike the idea of turning on / off the  
> envelope
> at the provider side, because then clients should be prepared to  
> parse the
> response in different ways. On the other hand, "normal" clients  
> (like our
> portals) should always ask for enveloped responses I think.
> Envelopeless interactions would probably be left to more specific  
> clients,
> like GoogleEarth, GUID resolution, RSS clients, which would  
> probably crash
> anyway if there's some error, regardless we turn on the envelope or  
> return
> a different tag. Am I correct?
> Sooo... I don't know what would be the best solution. :-(
> Maybe turning on the envelope is the way to go.

Hard decision. It probably doesnt matter that much as you lined out  
above.
Lets turn on the envelope for now until we find better reasons/ 
solutions.



>
>> 2) we allow to use COUNT in views. But how does a count get returned
>> if there is no envelope?
>>     - turn on envelope
>>     - ignore it
>
> Similar problem... similar doubt...
> Ignoring doesn't seem a good approach in this case.

The same thing. We should maybe raise a warning that envelope=False &  
count=True do not go together.
Envelope will be turned on then!


>
>> And some general questions:
>> 3) What did we agree on to return if there were no matches for the
>> query?
>>     - empty search element?
>>     - some explicit notion of an empty recordset, eg. <NoMatches>
>
> I think the answer for this one is here:
> http://ww3.bgbm.org/protocolwiki/PreliminaryProtocolNotes
Oops. yes, we have dealt with this already. So just nothing instead  
of some explicit notion.


>
>> 4) capabilities. not sure about our terminology.could/should we renme
>> these:
>>     - predefinedOutputModels  -->  trustedOutputModels
>>     - mandatory (concepts)  -->  required
>
> I agree with Javi's comments.
> Not sure about which name could replace predefined. It must  
> constrast with
> "custom". Maybe "preconfigured", "known", "available"...
> Required sounds better than mandatory.

What about sharedOutputModels ?
And I also like required better than mandatory.
lets change both?




> --
> Renato
>
>
>

AW: [PyWrapper-devel] queryforms does not work

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

thank javi,
the parameter supplied by the base class Page for all CP-webpages is =
called "baseurl" not base_url.
I corrected the queryforms kid template and now it works :)

-- Markus
 =20

> -----Urspr=FCngliche Nachricht-----
> Von: pyw...@li...=20
> [mailto:pyw...@li...] Im=20
> Auftrag von Javier privat
> Gesendet: Mittwoch, 31. Mai 2006 11:04
> An: pyw...@li...
> Betreff: [PyWrapper-devel] queryforms does not work
>=20
> Hi,
>=20
> I am having an error since last svn update. When I try to go=20
> to the QueryForms when I click in any datasource I always get=20
> and error:
>=20
>      for ev, item in stream:
>    File "/Users/javi/workspace/PyWrapper/webapp/queryforms/
> queryform.py", line 193, in _pull
> NameError: name 'base_url' is not defined
>=20
> And by the way, I get redirected to:
> http://localhost:8080/tapir/queryforms/training/search/abcd206
>=20
> Any idea where is this base_url defined?
>=20
> Javi.
>=20
>=20
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost=20
> and Risk!
> Fully trained technicians. The highest number of Red Hat=20
> certifications in the hosting industry. Fanatical Support.=20
> Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D107521&bid=3D248729&
dat=3D121642
> _______________________________________________
> PyWrapper-devel mailing list
> PyW...@li...
> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel
>=20

[PyWrapper-devel] queryforms does not work

[Javier de la T. <ja...@gm...>]

Hi,

I am having an error since last svn update. When I try to go to the  
QueryForms when I click in any datasource I always get and error:

     for ev, item in stream:
   File "/Users/javi/workspace/PyWrapper/webapp/queryforms/ 
queryform.py", line 193, in _pull
NameError: name 'base_url' is not defined

And by the way, I get redirected to:
http://localhost:8080/tapir/queryforms/training/search/abcd206

Any idea where is this base_url defined?

Javi.

AW: [PyWrapper-devel] Schema parsing

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

hi javi,
lot of visitors here lately and today.
milko knows about it already and I tranformed his schemas for him too.
i will close the ticket then, feels good!

curious what this first pywrapper tapir guy wants the software for. he =
no biologist, is he?

-- Markus
 =20

> -----Urspr=FCngliche Nachricht-----
> Von: pyw...@li...=20
> [mailto:pyw...@li...] Im=20
> Auftrag von Javier privat
> Gesendet: Mittwoch, 31. Mai 2006 11:00
> An: pyw...@li...
> Betreff: [PyWrapper-devel] Schema parsing
>=20
> Hi,
>=20
> I tried today the schema parsing with the latest revision=20
> from subversion and now it seems to work. Did you solve this=20
> Markus? Can you close the ticket in Trac?
>=20
> http://trac.pywrapper.org/pywrapper/ticket/33
>=20
> And we have to inform Milko who was waiting for it...
>=20
> And by the way he was using the service that you set up on=20
> bgbm3 that was using a pywrapper installation you have=20
> there... maybe you have to update this also so that the=20
> service works again.
>=20
> Javi.
>=20
>=20

[PyWrapper-devel] Schema parsing

[Javier de la T. <ja...@gm...>]

Hi,

I tried today the schema parsing with the latest revision from  
subversion and now it seems to work. Did you solve this Markus? Can  
you close the ticket in Trac?

http://trac.pywrapper.org/pywrapper/ticket/33

And we have to inform Milko who was waiting for it...

And by the way he was using the service that you set up on bgbm3 that  
was using a pywrapper installation you have there... maybe you have  
to update this also so that the service works again.

Javi.

[PyWrapper-devel] TAPIR pywrapper.org site launched

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

Dear all,

Sorry for cross-posting.

We are happy to announce the new collaborative home of the PyWrapper.org =
open source project:=20

http://www.pywrapper.org

Probably most of you don't know that pywrapper is the library behind the =
BioCASe Provider Software and the new TAPIR implementation that Markus =
had been working on with GBIF support in the last year.=20

The first priority is to support the revised TAPIR protocol, but we are =
also working on support for the WFS and SPICE protocols. A basic =
Configuration Tool to help data providers with their configuration and =
hopefully to update from previous BioCASe versions is under development =
with the help of SYNTHESYS funding.=20

We hope to include at some point also a local web-based search =
interface, the  Query Tool. This will allow data providers to gain =
instant webaccess to their databases with customisable skins (html =
templates) to integrate in existing designs.

The pywrapper library has always been released under the open source =
Mozilla Public License, but the development of it has mainly been done =
by one person alone. We want to alter this and become a truly open =
source project where everybody is invited to participate in the =
development. For this we have created a new working environment under

http://www.pywrapper.org

There you will find public access to the latest source code, a roadmap =
of the development, a report system to submit bugs and request and a new =
documentation system.

We have also created two mailing lists: =
pyw...@li... and =
pyw...@li... to improve communication between =
users and developers. Please feel free to join them at: =
http://trac.pywrapper.org/pywrapper/wiki/MailingLists


If you are interested in supporting the PyWrapper development you are =
very welcome and can do so in a variety of ways. We would be happy to =
welcome:

 * developers who want to participate in the core python components or =
just simple submodules like additional database syntax support.
 * testers and people interested in helping us with the documentation.
 * decision makers helping us to prioritize development according to the =
different project demands.
 * financial supporters to speed up development or add new compontents =
to the software


We hope you will like the new site and are excited to see the community =
grow. We are looking forward to work with you.


Markus & Javier

AW: [PyWrapper-devel] How Toc work in Trac

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

no idea.=20

-----Urspr=FCngliche Nachricht-----
Von: pyw...@li... =
[mailto:pyw...@li...] Im Auftrag von =
Javier privat
Gesendet: Freitag, 17. M=E4rz 2006 15:23
An: pyw...@li...
Betreff: [PyWrapper-devel] How Toc work in Trac

Hi Markus,

Do you know how table of contents work in Trac? I do not manage to =
understand it and I think it would be really useful specially for the =
documentation part.

If you go to

http://trac.pywrapper.org/pywrapper/wiki/TracGuide

You will see when editing that the table of contents that is on the =
right is imported using [[TracGuideToc]]. Do you know where this has =
been declared?

Cheers.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting =
language that extends applications into web and mobile media. Attend the =
live webcast and join the prime developer group breaking into this new =
coding territory!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D=
121642
_______________________________________________
Pywrapper-devel mailing list
Pyw...@li...
https://lists.sourceforge.net/lists/listinfo/pywrapper-devel

[PyWrapper-devel] Toc in Trac

[Javier de la T. <ja...@gm...>]

Sorry MArkus,

I think I found it... is pretty ugly solution so I don't know if we  
want to use this...
http://projects.edgewall.com/trac/browser/trunk/wiki-macros/ 
TracGuideToc.py

It is creating a macro that contains the toc

Actually I prefer a big page with the whole InstallationGuide than  
many different pages...

What do you think?

[PyWrapper-devel] How Toc work in Trac

[Javier de la T. <ja...@gm...>]

Hi Markus,

Do you know how table of contents work in Trac? I do not manage to  
understand it and I think it would be really useful specially for the  
documentation part.

If you go to

http://trac.pywrapper.org/pywrapper/wiki/TracGuide

You will see when editing that the table of contents that is on the  
right is imported using [[TracGuideToc]]. Do you know where this has  
been declared?

Cheers.

[PyWrapper-devel] Re: AW: interwiki links

[Javier de la T. <ja...@gm...>]

I couldn=B4t find one for news... I was actually thinking inn =20
developing my own little plugin to do an RSS from a controlled =20
vocabulary in the front page... but It can wait I think...

The other for comments is strange on security... so i am not so sure...

Maybe I just don=B4t do anything for the moment...

Did I tell you that I am on DADI? :) The problem is that they don=B4t =20=

have money anymore so I can forget about South Africa... shit!

And the TAG meeting of course... in Europe!

Cheers.


On 17/03/2006, at 14:55, D=F6ring, Markus wrote:

> I asked dave for the interwiki plugin already. wanna ask him for =20
> the news as well? shouldnt be too hard for him...
>
> -----Urspr=FCngliche Nachricht-----
> Von: Javier privat
> Gesendet: Freitag, 17. M=E4rz 2006 14:49
> An: D=F6ring, Markus
> Betreff: Re: interwiki links
>
> Uf Markus,
>
> There are a lot of cool plugins for trac...
>
> Specially I would like to see comments and news
>
> Users can comment on the configuration and so on... this is not =20
> going to be php.net but maybe...
>
> News I think it would be cool to have some news with rss support...
>
> Cheers.
>
> On 17/03/2006, at 13:21, D=F6ring, Markus wrote:
>
>> interwiki is not working out of the box in trac it seems.
>> http://trac-hacks.org/wiki/InterWikiPlugin
>>
>> its so nice to link to wikipedia, the protocol wiki, abcd and all the
>> others just by the wikiname without urls!
>>
>> m
>
>

[PyWrapper-devel] test from another account

[Javier de la T. <ja...@mn...>]

Here is a test from another account

[PyWrapper-devel] Commiting to subversion in response to a trak tricket

[Javier de la T. <ja...@gm...>]

Hi!

If you are commiting to svn because of a ticket, or you want to  
refeer to a ticket in the description of the commit use:

[ticket:1 This is a link to ticket number one]

This is important because trac will understand this and make  
interlinks between them.

Javi.

[PyWrapper-devel] test test

[Javier de la T. <ja...@gm...>]

test test

[PyWrapper-devel] Trac is more or less finished

[Javier de la T. <ja...@gm...>]

Hi all,

Well, hi Markus :)

I think I am done with editing the trac wiki. I think I have  
transfered everything that could be transfer. For example I did not  
copy the installation guide because it is totally wrong now. I have  
created a very basic one, for profis this should be ok.

  I also edited the other main categories, apart of the FAQ that is  
quite empty. You should review what I have written a little.

I think we can already remove the old wiki (better do a redirection  
or just a big link in the front page) and announce to the public that  
we have become a truely open source project...

For example we can start with a news item in BioCASe.org and a mail  
to the tapir list. Maybe we can even get a news item in the gbif.org  
site...

What do you think?

Javi.

[PyWrapper-devel] Testing the developers mailing list

[Javier de la T. <ja...@gm...>]

Hi!

Is this working?

Javi.