[MOBY-dev] [moby] Example ofa response message with SOAP envelope

Oswaldo Trelles ots at ac.uma.es
Wed Sep 20 08:39:36 UTC 2006


I agree with Mark in this is a programmer decision. In our case, the
INB-client only accepts the input (and descendants) declared during
service's registration. A similar situation arise when you ask for services
able to manage a given object type. In this case the client recognise as
valid object the registered type and its descendants

O.




----- Original Message ----- 
From: "Mark Wilkinson" <markw at illuminae.com>
To: "Javier de la Torre" <jatorre at gmail.com>
Cc: "Core developer announcements" <moby-dev at lists.open-bio.org>
Sent: Tuesday, September 19, 2006 6:53 PM
Subject: Re: [MOBY-dev] [moby] Example ofa response message with SOAP
envelope


> Well, I don't know how other service providers do it, but I seldom
> validate the incoming XML *at all*.  I simply use an XPath query or
> something like that to reach into the XML document to get the pieces
> that I expect to be in there (based on whatever I registered as my input
> data type).  If they are not there, I throw an error.
>
> It is possible, of course, to query the ontology to make sure that what
> you have received is a child of what you registered as consuming... but
> that's a lot of overhead, and besides, what are you going to do if it
> isn't a child?  fail with an error :-)  so I simply fail with an error
> if I don't find what I want, and skip the expensive validation step
> altogether.
>
> M
>
>
>
>
> On Tue, 2006-09-19 at 18:34 +0200, Javier de la Torre wrote:
> > Ups!
> >
> > And how does the services work? I mean, do they have to connect to
> > the registry to check the relations of the objects they serve with
> > what other people might be sending them? Or is it that they just take
> > the string, in my case, and do something with it? If it is the second
> > then a user, stupidly, could be sending an object to a service that
> > is not necessarily inheritanced from the data type he understands and
> > he will be using it. Of course there is nothing wrong to provide
> > stupid answers to stupid questions, but, is it like this?
> >
> > The, can I just take the content from the <moby:string> in the income
> > message and expect that it is actually a ScientificName?
> >
> > Thanks.
> >
> > Javier.
> >
> >
> > On 19/09/2006, at 18:26, Mark Wilkinson wrote:
> >
> > > On Tue, 2006-09-19 at 18:22 +0200, Javier de la Torre wrote:
> > >> information I need so I think I am safe because inside your
> > >> MyScientificName there will still be a ScientificName. I dont mind
> > >> where in the XML it is because XSLT will find it, hopefully!
> > >
> > >
> > > Nope, not quite :-)  ScientificName (as a tag name) will not be inside
> > > of MyScientificName; however the *content* of MyScientificName will
> > > include all of the same elements as the *content* of ScientificName
> > >
> > > MyScientificName to ScientificName is an inheritence relationship,
> > > not a
> > > container relationship
> > >
> > > M
> > >
> > >
> > > _______________________________________________
> > > MOBY-dev mailing list
> > > MOBY-dev at lists.open-bio.org
> > > http://lists.open-bio.org/mailman/listinfo/moby-dev
> >
> -- 
> Mark Wilkinson
> Asst. Professor, Dept. of Medical Genetics
> University of British Columbia
> PI in Bioinformatics, iCAPTURE Centre
> St. Paul's Hospital, Rm. 166, 1081 Burrard St.
> Vancouver, BC, V6Z 1Y6
> tel: 604 682 2344 x62129
> fax: 604 806 9274
>
> "Since the point of a definition is to explain the meaning of a term to
>    someone who is unfamiliar with its proper application, the use of
> language that doesn't help such a person learn how to apply the term is
>  pointless. Thus, "happiness is a warm puppy" may be a lovely thought,
>                      but it is a lousy definition."
>                                                                 Köhler et
al, 2006
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev




More information about the MOBY-dev mailing list