Loading ...
Sorry, an error occurred while loading the content.

986Re: [soapbuilders] Re: The Interop tests and BDG (was : some questions/observations re: BDG)

Expand Messages
  • Paul Kulchenko
    Apr 1, 2001
    • 0 Attachment
      Hi, Glen!

      > Paul, I strongly disagree with this idea. The whole XML Protocol /
      > Web
      > Service philosophy is about systems interoperating in a fairly
      > loosely
      > coupled fashion. One of the exciting things that SOAP buys you in
      > this
      > regard is orthogonal extensibility - i.e. headers which let me
      > throw
      > arbitrary extensions into our communication without your needing to
      > know
      > about them up front. The mustUnderstand attribute, which lets me
      > tell you
      > what extensions are really critical in my (the sender's) eyes, is a
      I'm not even trying to argue with it. First, I wanted to show
      ambiguity of sending something that server MAY not understand. I
      think mustUnderstand is right and practical solution, I'm just trying
      to draw the line somewhere (notice that it may be impossible). If you
      want to add mustUnderstand in BDG (even if we should), you need to
      add Headers also, if you have headers, you need to add actor,
      intermediary etc, otherwise failing on mustUnderstand will do the
      WRONG thing. Here we are coming to SOAP 1.1. Why? Because though spec
      is unclear in some places and ambigous in others, it's still simple,
      consice and there is no so many places where we can cut something.
      Again, I'm not discussing importance of mustUnderstand, but
      implementing it you'll finish somewhere close to full implementation.
      Personally, I will support mustUnderstand, as well as many other
      things, though I'm weak on WSDL side I'll improve schema support
      also.

      btw, speaking about mustUnderstand. I asked this question already,
      but didn't get any answer. ebXML draft says about REQUIREMENTS for
      mustUnderstand on some elements inside Body. SOAP spec is clear (in
      my view) on using mustUuderstand only for Header elements. How it
      should be resolved? What's the procedure for handling mustUnderstand
      on Body subelements? What will you do with your implementation in
      this case? Or I got something wrong?

      Best wishes, Paul.

      --- Glen Daniels <gdaniels@...> wrote:
      > Paul sez:
      > > Hi, Keith!
      > >
      > > > > When the BDG says to do X, does it mean you don't have to
      > accept
      > > > Y
      > > > > (where Y is perfectly acceptible SOAP, such as a datatype not
      > > > > mentioned in the BDG)?
      > > I think answer should be 'no'.
      >
      > +1
      >
      > > > > Corrolary: Will a BDG implementation correctly fault when
      > sent a
      > > > SOAP
      > > > > Header it doesn't understand?
      > > I think answer is 'no' again. Why? If I send
      > > <SOAP-ENV:Header><my:something xmlns:my="..."/></SOAP-ENV:Header>
      > to
      > > MS tollkit will it fail request? I don't think so, unless I
      > specify
      > > mustUnderstand attribute (and even then only if mustUnderstand is
      > > supported). The same thing shoudl be true about BDG. For me it's
      > just
      > > common denominator, otherwise how will you know that something
      > you
      > > need it supported on other side without testing it first? I can
      > send
      > > message with multiple references and there is no way to tell
      > > beforehand, will server handle this request or not. Now imagine
      > that
      > > server has no knowledge about id/refs. Will this server fail such
      > > request? 99% that answer is no, because it'll just count IDs as
      > > another attribute, so implementation will get some STRANGE
      > values,
      > > but occasionally they could be perfectly valid for it. That's why
      > I
      > > tried to cover as wide field as possible in my implementation to
      > > avoid surprises of such kind.
      > >
      > > Speaking about BDG, it's trying to define minimal subset of
      > > requirements. Consider practical point. Userland implemented BDG
      > and
      > > stoped their development. Will they be able to interoperate? yes.
      > > Will they fail request with mustUnderstand? probably no. Is it
      > > important for their case? probably not. That's limitation of
      > their
      > > implementation. Why whould you send Header with mustUnderstand
      > > without having proper contract with them? Big question is will
      > OTHER
      > > stop at this point? I don't think so. I don't even think that
      > Dave
      > > will :). imho :)
      >
      > Paul, I strongly disagree with this idea. The whole XML Protocol /
      > Web
      > Service philosophy is about systems interoperating in a fairly
      > loosely
      > coupled fashion. One of the exciting things that SOAP buys you in
      > this
      > regard is orthogonal extensibility - i.e. headers which let me
      > throw
      > arbitrary extensions into our communication without your needing to
      > know
      > about them up front. The mustUnderstand attribute, which lets me
      > tell you
      > what extensions are really critical in my (the sender's) eyes, is a
      > REQUIRED
      > part of the SOAP spec, and should, IMHO, be supported at least
      > enough to
      > return a fault if you get a mustUnderstand header and you a) don't
      > grok it,
      > or b) don't process headers at all. I just recently changed the
      > Apache
      > implementation to do this, and it's pretty trivial - if you don't
      > do
      > headers, just look for anything in the header element with
      > mustUnderstand="1", and fault if you see them.
      >
      > I would like to see this get added to the BDG (which I can't seem
      > to get to
      > at the moment, but I assume it's not in there as yet...), actually.
      > If this
      > sort of thing (i.e. MUSTs in the SOAP spec) can be dropped, I have
      > some
      > major worries about obtaining any sort of true interoperability as
      > web
      > services start to really ramp up and use this stuff.
      >
      > --Glen
      >
      >
      >
      > ------------------------ Yahoo! Groups Sponsor
      >
      > To unsubscribe from this group, send an email to:
      > soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      >
      >


      __________________________________________________
      Do You Yahoo!?
      Get email at your own domain with Yahoo! Mail.
      http://personal.mail.yahoo.com/?.refer=text
    • Show all 48 messages in this topic