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

BDG comments

Expand Messages
  • Gisle Aas
    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
    Message 1 of 3 , Apr 2 9:29 AM
      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
    Your message has been successfully submitted and would be delivered to recipients shortly.