SOAP BDG: Mission Impossible?
We didn't receive any relevant comment about our considerations on
SOAP posted at:
For this reason we decided to write you a mail.
Given that we programmed a full SOAP 1.1 implementation, server-side
and client-side, we are able to enumerate some points that makes a
SOAP parser complex and slow. Points that should be considered in a
SOAP "Lite" version, otherwise, why do we need a "lite" version?
Relevant examples could be that every namespace-fixup within the
envelope requires another processing step, or that the parameter order
is defined as "not significant".
All these features are very nice, but make the parser very complex
too. Are these features really needed and used? In some cases,
limitations could be not too restrictive as thought and could simplify
very much the implementation of a parser.
Another big issue, given that SOAP is a simple OBJECT access protocol,
is how do we address metadata information of objects (such as a unique
server-side identifier) within the envelope? Can we give a formal
specification in SOAP 1.2?
We were quite thrilled about your BDG, because we thought that SOAP
needed to gain momentum and support from the "small" developers. This
in order to hinder Microsoft from "Embrace and Extend" practices, as
they did with kerberos. We would like to have a small, deterministic,
easy-but-complete specification of SOAP (your BDG) that could be
deployed *now* without waiting for Microsoft lock-ins.
We want to support BDG. We would like to see "def-before-use" in
namespaces (makes parsing easier and faster), object references in the
header (makes remote method invocation formalises), and order of
parameter relevant (makes parsing more deterministic, and easier) in
the BDG. These could be seen as restrictions, but they facilitate and
formalise the parsing step. I mean, we come from the Prof. Wirth
Gabrio Rivera & Roberto Brega