Re: [wsrf] WS-BaseFault & Java

[Steve Graham <sggraham@us.ibm.com>]

Would it not be possible to "nest"
the Fault Messages using the wsbf:BaseFault element information item?

(I know this doesn't use the preferred
approach of declaring a new extension with base="BaseFaultType",
but I wanted to keep the example simple)

  <BaseFault>
     <Timestamp>...</Timestamp>
     <ErrorCode dialect="ZOSError">abend1234</ErrorCode>
     <Description
xml:lang="geek">something really technical </Description>
     <FaultCause>
        <BaseFault>
         
 <Timestamp>...</Timestamp>
         
 <ErrorCode dialect="JavaExceptionClass">com.ibm.zos.errors.Exception</ErrorCode>
?
         
 <Description>INSERT exception trace HERE</Description>
*
        </BaseFault>
     </FaultCause>
  </BaseFault>

You are correct that none of the element
information items in BaseFault support open attribute or open element extensibility.
 We considered that the nesting approach would address the approach
you suggested.

sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++

Samuel Meder <meder@mcs.anl.gov> 06/16/2004 06:25 PM Please respond to meder

To:        wsrf-oasis <wsrf@lists.oasis-open.org>         cc:        Jarek Gawor <gawor@mcs.anl.gov>         Subject:        [wsrf] WS-BaseFault & Java

We've been struggling a little with how to present
a Java exception
stack trace to clients:

      * The ErrorCode field seems very much geared towards
presenting
        legacy error codes and has a maxOccurs of 1
so we would not be
        able to communicate the stack trace and the
error code if the
        stack trace were caused by a error in a legacy
call
      * The Description field should contain a plain language
        description of the fault. Again, not exactly
a perfect fit.

The solution we see is to either rename ErrorCode to something more
generic, say ErrorDetails, and change maxOccurs to unbounded or to allow
the annotation of the Description field with something indicating it's
content (we may only want to present certain type of content to the user
at the default setting). 

In general I feel that both the ErrorCode and Description elements
should have been declared allowing for attribute extensibility as you
can't (afaik, please correct me if I am wrong, I'm not a schema expert)
add attributes to these elements via schema extension. 

/Sam

-- 
Sam Meder <meder@mcs.anl.gov>
The Globus Alliance - University of Chicago
630-252-1752