How about this approach:

We follow WS-I BP guidelines by default, but we permit users to
override those defaults using switches (rather than the other way
around).

In other words -- if you don't specify any extra switches, java2wsdl
generates a WS-I compliant WSDL document.

Anne


On Sat, 19 Mar 2005 10:21:03 -0500, Glen Daniels <[EMAIL PROTECTED]> wrote:
> Hi Anne:
> 
> Actually, both SOAP 1.1 and SOAP 1.2 *explicitly* allow zero or more
> "detail entry" elements inside <detail>, and Axis 2 should definitely
> support this (as Axis 1 does).  When using a WSDL 1.1 fault binding, it
> is true that there should be only a single part (like there is only a
> single element in WSDL 2.0), but that part definition simply defines a
> distinguished detail entry - it doesn't prevent other ones.  Axis 1 uses
> this facility to send things like stack traces inside the detail in
> parallel with the actual data-bound XML for the specific fault type.
> 
> If WS-I BP specifies a particular restriction such as "only one child",
> that's fine and we can put in a check for such a thing, but only when we
> have a "BP compliance" flag which is switched on.
> 
> Thanks,
> --Glen
> 
> Anne Thomas Manes wrote:
> > I'm talking about SOAP 1.1.
> >
> > And no. The detail element may not have more than one child element.
> > Faults do not have parameters. They must follow the rules of
> > document/literal. Therefore the detail element may contain only one
> > child element. That child element may have any number of attributes
> > and/or child elements.
> >
> > So this is correct:
> >
> > <soap:Body xmlns:ns="urn:myFault">
> >   <soap:Fault>
> >      <faultcode>soap:Client</faultcode>
> >      <faultstring>Something went wrong</faultstring>
> >      <detail>
> >         <ns:myFault>
> >            <ns:reasonCode>123<ns:reasonCode>
> >            <ns:moreInfo>blah blah<ns:moreInfo>
> >          </ns:myFault>
> >       </detail>
> >    </soap:Fault>
> > </soapBody>
> >
> > But this is not:
> >
> > <soap:Body xmlns:ns="urn:myFault">
> >   <soap:Fault>
> >      <faultcode>soap:Client</faultcode>
> >      <faultstring>Something went wrong</faultstring>
> >      <detail>
> >          <ns:reasonCode>123<ns:reasonCode>
> >          <ns:moreInfo>blah blah<ns:moreInfo>
> >       </detail>
> >    </soap:Fault>
> > </soapBody>
> >
> >
> > On Sat, 19 Mar 2005 10:02:51 +0600, Eran Chinthaka
> > <[EMAIL PROTECTED]> wrote:
> >
> >>Ok. Is this what SOAPFault detail should be. (Remember current impl is still
> >>SOAP 1.1 compliant only, not SOAP 1.2).
> >>
> >>SOAPFault MAY have only on detail element. That detail element can have any
> >>number of children.
> >>
> >>Is that ok ?
> >>
> >>If that's the case, I just will have to provide a method to add detail
> >>entries to detail element and change if (detailElement != null) block to
> >>return detail element.
> >>
> >>
> >>-- Eran Chinthaka
> >>
> >>
> >>>-----Original Message-----
> >>>From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]
> >>>Sent: Saturday, March 19, 2005 2:02 AM
> >>>To: [email protected]
> >>>Subject: Re: [Axis2]Doubt on Detail Element in SOAPFault
> >>>
> >>>The <detail> element should have one child element.(That element may
> >>>have as many attributes and child elements as you like.) When you
> >>>specify the fault message, it should have at most one part, and it
> >>>should reference an element defined in your types section. Faults must
> >>>be encoded using document/literal.
> >>>
> >>>- Anne
> >>>
> >>>
> >>>On Thu, 17 Mar 2005 15:47:47 +0530, Shahi, Ashutosh
> >>><[EMAIL PROTECTED]> wrote:
> >>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>Hi Guys,
> >>>>
> >>>>            Looking at the SOAPFaultImpl class of the OM implementation
> >>>>gives me the feeling that the fault can have only one detail entry kind
> >>>
> >>>of
> >>>
> >>>>information.  In the setDetailInformation method I see that each time we
> >>>>create a new detailElement and add the passed detail node as child to
> >>>
> >>>it.
> >>>
> >>>>Also getDetailInformation assumes that detailElement has only one child
> >>>
> >>>as I
> >>>
> >>>>see it returning a single node instead of an iterator.
> >>>>
> >>>>
> >>>>
> >>>>The general structure in Axis 1.2 is that we have a Detail Node which
> >>>
> >>>can
> >>>
> >>>>have > 1 detail entry element. The SOAP spec says the same. Is it that
> >>>
> >>>we
> >>>
> >>>>are restricting the user to create only one detail entry element in OM
> >>>
> >>>or am
> >>>
> >>>>I missing something?
> >>>>
> >>>>
> >>>>
> >>>>Ashutosh
> >>>>
> >>>>
> >>
> >>
> >
>

Reply via email to