I prefer #2 -- dims
On Sun, 20 Mar 2005 20:03:53 +0600, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > 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). > > Agreed. > > >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. > > Me too used the detail element to send the stack trace in Axis 2. > > > > > 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. > > Agreed. This one child restriction is provided by WS-I BP only. So I also > agree with Glen to implement SOAP 1.1 (and/or SOAP 1.2) as usual and set a > flag for BP compliance. > > I have a small doubt in these kinds of cases. Meaning, the spec clearly says > something and the BP restricts that. I think its better to have a general > policy to handle these sort of things. > > What do you all think ?? > > We have two options; > > 1. Implement the core to be BP compliant. i.e. when there is a > conflict between what spec says and what BP says, the BP rules and we > implement that *only* > 2. Implement the core to be compliant with the original spec. But > provide a flag for BP compliance, so that BP will rule, when the flag is on. > > I prefer Option 2. > > Thanks, > -- Eran Chinthaka > > > > > 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 > > >>>> > > >>>> > > >> > > >> > > > > > -- Davanum Srinivas - http://webservices.apache.org/~dims/
