[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrf] BaseFaults comments from HP
Bryan, the intent of the charter statement is to restrict the normative statements in the WS-RF specifications to being binding neutral. If we defined normative SOAP-specific bindings for WSRF-BF and not for the other specifications then we would have an inconsistent degree of specificity across our specs. The existing non-normative SOAP examples in WSRF-BF are the agreed resolution to issue 106 (per minutes of May 6) which addressed the means by which BF should be mapped to SOAP faults. In that resolution we agreed to keep the text non-normative. Regards, Ian Robinson STSM, WebSphere Messaging and Transactions Architect IBM Hursley Lab, UK ian_robinson@uk.ibm.com "Murray, Bryan P." <bryan.murray@hp. To com> Ian Robinson/UK/IBM@IBMGB cc 01/09/2005 21:47 <wsrf@lists.oasis-open.org> Subject RE: [wsrf] BaseFaults comments from HP Ian, Regarding your comment on #2: I interpret the charter to be speaking about transport protocols. I would not consider SOAP to be a transport protocol. Furthermore, the WS-* specifications are centered around SOAP even if they do not normatively require it. Right now the BaseFaults defines a fault type and element. Without a requirement that it be placed in a SOAP fault, someone could return an element derived from BaseFaultType as the only child of SOAP Body and be compliant with the specification. Do we want to allow this behavior? Bryan -----Original Message----- From: Ian Robinson [mailto:ian_robinson@uk.ibm.com] Sent: Thursday, September 01, 2005 1:34 AM To: Murray, Bryan P. Cc: wsrf@lists.oasis-open.org Subject: Re: [wsrf] BaseFaults comments from HP Regards, Ian Robinson STSM, WebSphere Messaging and Transactions Architect IBM Hursley Lab, UK ian_robinson@uk.ibm.com "Murray, Bryan P." <bryan.murray@hp.com> wrote on 01/09/2005 01:46:47: > I have done a critical review of WS-BaseFaults. I am listing several > issues below but most of them are editorial. All comments are from the > Public Review version. > > Bryan > > > > Discuss in TC? > -------------- > > 1. line 240: why does it matter what the name of the message part is? > I suggest removing this requirement. > Yes. We don't even follow this constraint in our own fault definitions (e.g. ResourceUnknownFault definition). > 2. The BaseFault type is defined, but there is no where except in > examples where there are instructions about how to place an element of > this or a derived fault pe into a SOAP fault message. The reader never > knows that this element is placed as a child of the SOAP fault > detail/Detail element except by examining the examples. We have no normative references to SOAP or any other specific binding. "The consideration of protocol-specific bindings." is declared out of scope in the charter so I think the non-normative examples are as specific as we should go. I believe the non-normative examples are quite clear.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]