ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> soapbuilders
soapbuilders
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

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved