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

750Re: [soapbuilders] Outstanding BDG issues

Expand Messages
  • Sam Ruby
    Mar 31, 2001
    • 0 Attachment
      Dave Winer wrote:
      > My motive in wanting to do the BDG is to "get on with it." Right now my
      > whole development team is sucked into SOAP interop. This has to change.
      > have customers who are waiting for us, and lives to live independent of
      > process. It must reach closure. Just before I posted the link to BDG,
      > had posted a message basically giving up. Clearly BDG was needed, perhaps
      > not by Microsoft or Ken MacLeod, but *we* needed it, and this is an open
      > process, and we have worked really hard to make it conform, yet the
      > continue.

      Just an overall comment on the process: an essentially unannounced 48 (or
      72) hour window with the expectation to reach closure is not entirely fair
      for those of us with preexisting "customers waiting for us, and lives to
      live independent of this process"...

      That being said, I am *VERY* pleased with the progress that is occurring
      towards interop - whether the BDG was the catalyst, the end-point, or the
      timing was entirely coincidental (my leanings are towards the first of the
      three possibilities, but in the long run and if this is truly an egoless
      environment, it matters not).

      Examples of positive outcome: the identification of the misspelling of
      "infinity" by Apache's Soap implementation. Despite the spec being clear,
      we got it wrong. However, this could have gone undetected for a long
      period of time as the Apache client and server implementations were
      compatibly incorrect.

      More troublesome is the thoughts of a subset. An example of which is that
      it appears that the current implementation of Frontier does not support
      exponential notation in floating point numbers. I see no issue with
      Frontier never producing numbers with such notation, but it becomes
      problematic if such numbers can not be consumed by this implementation. I
      pick on this item, not because of any ill will towards Frontier, but as a
      concrete and specific example of the dangers of subsetting the SOAP 1.1
      specification. And even if the specific problem is addressed, the general
      problem remains.

      Less troublesome is the thought of extensions. For example, if a popular
      new encoding arises with widespread support, then we all benefit. I
      personally would prefer if such extensions were documented separately and
      clearly marked as optional. It would also have been my preference to first
      establish a basis of interop before discussing extensions, but if the
      consensus is that doing both together helps speed up the process, then I
      will not object.

      Insert obvious reference to the dangers of subsetting, embracing, and
      extending; in the name of "get[ting] on with it". The dangers are the
      same whether you think of yourself as wearing a white had or a black

      Meanwhile, back to my life independent of this process. It seems my wife
      wants me to dig a hole in the backyard for her...

      - Sam Ruby

      P.S. Next week is actually worse for me personally.
    • Show all 23 messages in this topic