"Andy Dingley" <> wrote in message
news:...
> On Tue, 28 Sep 2004 03:54:56 GMT, "JustSomeGuy" <>
> wrote:
>
> >When you have an xml message and you want to extract a particular
> >item, what is the normal search method?
>
> You need to be more careful with your terminology, or you'll get
> bitten in the future. (but if you're asking this question, it shows
> you're at least thinking about the right stuff).
>
Ok what is the 'correct' terminology? Lest the gods of xml smite me.
> You're using some complex technology here. You have XML, SOAP, then
> some application on top of that. Now if you do it right, all this stuf
> fis your friend - an XML tool handles the XML for you, an app server
> takes care of SOAP, and some little EJB knows how to sort out the
> application level stuff. If you mix it all up though, things get
> awkward - you'll find yourself trying to write what should be a very
> simple bean that knows about the
> schemas-upnp-org:service:WANIPConnection stuff, but instead you've
> coded all sorts of SOAP related stuff into it. If you don't
> appreciate _why_ this is bad, go and look up the terms "coherence and
> coupling".
>
My application has classes for soap and html and for xml.
Sorry whats an EJB (A Java Bean?).. You must excuse me I'm a c++ guy.
>
> You could write any bit of XPath in here, and it would extract your
> data
>
XPath eh.. Ok So this string of text is a 'normal' way of requesting
the text your looking for?
>
/s:Envelope/s:Body/u:GetExternalIPAddressResponse/u:NewExternalIPAddress/tex
t()
> would do it. However that's Bad Coding.
>
>
Ok thank you I'll keep that in mind.
> Anything with
> /s:Envelope/s:Body/*
> in it is bad. That's coupling the SOAP envelope and body together,
> and that's a no-no for SOAP. You're supposed to be able to pass
> bodies around independently, passing them between different envelopes
> as SOAP does some routing for you. OK, so it doesn't happen much, but
> it _might_.
>
>
> Anything with
> //s:*//u:*
> in it is bad. That's coupling SOAP and the u namespace (the
> application protocol) together. Why should your u-specific EJB know
> anything about SOAP ? Why should it be coded so that it can _only_
> work with messages arriving from a SOAP source ?
>
I see your point.
> I've seen this piece of code _so_ many times 8-(
> I've even seen some idiots wrap faked-up SOAP bodies around the data
> payload, to work around their broken code. These people should be in
> marketing.
>
I wish I were... I'd be making more money!
>
> The right XPath is something like
> u:GetExternalIPAddressResponse/u:NewExternalIPAddress/text()
> You'll note that this doesn't work !
>
> To get it to work, you need to pass it a starting context that's the
> content of s:Body. This is good practice (if you're using some sort
> of pre-written framework for implementing SOAP, it'll probably do this
> for you). The advantage is that your own EJB (or whatever) is now
> independent of SOAP and doesn't care _where_ your
> <u:GetExternalIPAddressResponse> element came from.
>
>
>
> //u:NewExternalIPAddress/text()
> _might_ work, but I'd advise against it. Can you guarantee that this
> will always be the right element ? What would happen if the body
> started containing it as a child of some other element as well, like
> this?
>
Thanks for a great reply.
This was the exact question I had on my mind as well.. What if its not
the right element... Well I suppose that that means that Microsoft changed
the interface to their InternetGatewayDevice specification... (Something
microsoft would never consider doing

Then of course I'd be forced to
change the software. I am assuming that no matter what interface you are
dealing with you need to know the interface in order to deal with it.
Very much like dealing with a c++ class... when a member function changes
then so must the software that called it. Or have I missed the point?
My next question of course is about the namespaces 'u' and 's'. These
were the namespace I defined when I made the original request so I assume
the server preserved it for me?
> > <s:Body>
> > <u:GetExternalIPAddressResponse
> >xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
> > <NewExternalIPAddress>
> > 168.46.10.14
> > </NewExternalIPAddress>
> > </u:GetExternalIPAddressResponse>
> > <u:GetSomeRandomRubbish
> >xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
> > <NewExternalIPAddress>
> > 168.46.10.14
> > </NewExternalIPAddress>
> > </u:GetSomeRandomRubbish>
> > </s:Body>
>
>
>