BDG comments
by Gisle Aas other posts by this author
Apr 2 2001 4:29PM messages near this date
RE: [soapbuilders] Re: The Interop tests and BDG (was : some questions/observations re: BDG)
|
RE: [soapbuilders] Re: The Interop tests and BDG (was : some questions/observations re: BDG)
Hi,
I would like to add some comments to the BDG. I have been working on
the SOAP implementation that we ship with our PerlEx product. In our
implementation method prototypes are typically declared upfront. From
this we automatically generate WSDL and because of this normally don't
provide explicit typing (xsi:type attribute) in the the SOAP messages
we generate. I would like to make our implementation BDG compliant
and have the following comments and suggestions.
These comments are based on the BDG tagged with "4/2/01".
1) Boolean values.
I think the boolean literals should be "true" or
"false". The BDG examples under "Scalar Values" says 1 or 0.
Example under arrays says "false".
This XML Schema spec SOAP/1.1 reference says "true"/"false":
http://www.w3.org/TR/1999/WD-xmlschema-2-19991217/datatypes.html#dt-boolean
I suggest the example under "Scalar Values" change to "true" and
"false" with a comment that says that application are encouraged
to also understand 1 and 0.
Our current implementation will actually fault if passed something
else than "true" and "false".
2) Structs
Why should not structs have an xsi:type attribute?
In our implementation we can either turn off explicit typing (in
which case only things prototyped with "anyType" get an xsi:type
attribute) or it can be turned on (in which case everything will be
typed, including structs.) It would be easier for me if struct
had some xsi:type attribute, because then I only need to turn on
explicit typing and things should work. With the current BDG I
need to make a special hack for structs.
3) Null values
I don't think you should use <nil> as the element name. For instance,
if our implementation returns a single nulled string it will generate
something like this:
<XxxResponse>
<Result xsi:type="xsd:string" xsi:null="true"/>
</XxxResponse>
I also think it should be <xxx xsi:null="true"/> (i.e. "true" instead
of "1"). See http://www.w3.o-19991217/rg/TR/1999/WD-xmlschema-1-19991217/
4) Unqualified methods
By default our implementation will not use qualified method
elements. I think BDG should allow that. The first request
example would then be:
<SOAP-ENV:Body>
<getStateName>
<param1 xsi:type="xsd:int"> 41</param1>
</getStateName>
</SOAP-ENV:Body>
SOAP already have 2 other URIs to dispatch from. Why make
the 3rd one mandatory for BDG.
5) XML Namespace prefixes.
Do they have to be "SOAP-ENV:", "SOAP-ENC:" and "xsd:", "xsi:" and
"m:" or can I choose whatever I want. I would prefer the later.
If they have to be like that I think BDG should state this.
6) BDG SOAP Header
I propose that we add a BDG header to the request. This will be a
hint the server that it should try to format the response according
to the BDG rules: explicit typing, specific namespace prefixes,
specific element names on response "XxxResponse", "Result" and
untyped struct elements.
Example:
<SOAP-ENV:Envelope>
<SOAP-ENV:Header>
<bdg:bdg xmlns:bdg="http://www.soapware.org/bdg"/>
</SOAP-ENV:Header>
<SOAP-ENV:Body> ...
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The element should not have the mustUnderstand set because things
might work out even if the server did not known anything about
this header.
Regards,
Gisle Aas
|