750Re: [soapbuilders] Outstanding BDG issues
- Mar 31, 2001Dave 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 ofthis
> process. It must reach closure. Just before I posted the link to BDG,Tony
> had posted a message basically giving up. Clearly BDG was needed, perhapsflames
> 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
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
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.
- << Previous post in topic Next post in topic >>