RE: [wsrf] Reopen Issue WSRF110

["Murray, Bryan P." <bryan.murray@hp.com>]

Tom,

Could you explain how fields (stack trace, process id, etc.) can be added using proposal i). Without an extension point somewhere, there is no place to put additional fields. If the xs:any is removed, BaseFaultType has no extension point.

Bryan

-----Original Message-----
From: Tom Maguire [mailto:tmaguire@us.ibm.com] 
Sent: Thursday, June 23, 2005 6:17 AM
To: Peter Niblett
Cc: Murray, Bryan P.; Yalcinalp, Umit; wsrf@lists.oasis-open.org
Subject: RE: [wsrf] Reopen Issue WSRF110

Peter Niblett <peter_niblett@uk.ibm.com> wrote on 06/23/2005 07:00:22 AM:
> I can see three ways to solve the validation problem
>
> i)  remove the xs:any altogether (though this would remove the ability 
> to do 2)
> ii) move the xs:any earlier in the sequence. The important thing here 
> is that it must be followed by at least one mandatory element, so that 
> there is a clear separator between the xs:any and the derived type additions.
> Fortunately BaseFaultType has one mandatory element (Timestamp).
> iii) leave the xs:any at the end, but wrap it in a minOccurs="0"
containing
> element, so that the xs:any and the extension elements are at 
> different levels and can't collide.

As I recall the desire was to be able to treat BaseFaultType extensions as BaseFaultTypes even though they had additional extension information.
I believe this can be done without the use of any of the above options.

The requirement to extend the BaseFault without doing type extension for stack trace or process id (as Bryan eludes to below) would be met by option i.

I would opt for option i...

>
>

>              "Murray, Bryan

>              P."

>              <bryan.murray@hp.
To
>              com>                      "Yalcinalp, Umit"

>                                        <umit.yalcinalp@sap.com>, "Tom

>              23/06/2005 00:00          Maguire" <tmaguire@us.ibm.com>,

>                                        <wsrf@lists.oasis-open.org>

>
cc
>

>
Subject
>                                        RE: [wsrf] Reopen Issue WSRF110

>

>

>

>

>

>

>
>
>
>
> At the last face-to-face we talked about some issues with BaseFaults, 
> one of which was the potential of having a generic fault handler to 
> which all fault messages would be sent. With WS-Addressing having the 
> FaultTo
header,
> this becomes even more attractive.
>
> If a fault handler interprets all messages it receives as being an
instance
> of either BaseFaultType or a derived type, this will work even without
the
> use of the xs:any.
>
> However, I have had requests from developers to add extension 
> capability
to
> allow extra information to be added to fault messages such as stack 
> trace or process id. This type of information may not always be 
> appropriate for all fault messages or in all environments so we don't 
> want to add these elements to the base type. However, allowing them to 
> be added in a
generic
> way to any fault message can provide some very valuable information 
> for tracking down the root cause of the fault or for debugging.
>
> In order to solve the validation problem, we can move the xs:any from 
> the end of the xs:sequence in BaseFaultType to the beginning of the 
> xs:sequence. With this change, extension elements will no longer 
> conflict with elements inserted as part of the xs:any.
>
> Bryan
>
>
> -----Original Message-----
> From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
> Sent: Wednesday, June 22, 2005 1:35 PM
> To: Tom Maguire; wsrf@lists.oasis-open.org
> Subject: RE: [wsrf] Reopen Issue WSRF110
>
>
>
> > -----Original Message-----
> > From: Tom Maguire [mailto:tmaguire@us.ibm.com]
> > Sent: Monday, Jun 20, 2005 9:38 AM
> > To: wsrf@lists.oasis-open.org
> > Subject: [wsrf] Reopen Issue WSRF110
> >
> > The proposed recommendation to WSRF110 was the addtion of an xs:any 
> > ##other to the BaseFaultType.  This introduces a schema validation 
> > error for extensions.
> >
> > Text from Peter Niblett:
> > If you extend the BFType in another namespace (as we do) and add 
> > extra elements in that extension, then the schema that does the 
> > extension (e.g.
> > WSN)  violates the Unique Particle Attribution constraint as it 
> > becomes non-determnistic. This is because BaseFaultType ends with 
> > <xs:any namespace="##other" minOccurs="0">. So in the extended fault 
> > type you can't tell whether elements in an extended instance are to 
> > be validated by this <any> or by the elements in the extended type
> >
> >
> > We need to reopen and revisit the proposed recommendation (and 
> > subsequent action).
>
> Somehow my previous email got sent out before we I had the chance to 
> complete it. I was not going to say anything profound, but UPA is a
common
> problem that is encountered by others and discussed within the XML 
> Schema users workshop which I am attending this week [1]. Don't expect 
> UPA rule
to
> dissappear, so we need to reopen the issue.
>
> Can someone refresh our memory why we added the xs:any to the base 
> type instead of new extended fault types to add their own elements instead?
>
> Thanks,
>
>
> >
> >
> >
> > Tom
> >
>
> --umit
>
> >
> > Frey's Law: "Every 5 years the number of architecture components 
> > double and the ability to comprehend them halves"
> >
>
> [1] http://www.w3.org/2005/03/xml-schema-user-cfp.html
>
> >
> > Perfection is achieved, not when there is nothing more to add, but 
> > when there is nothing left to take away.   - Antoine de 
> > Saint-Exupery
> >
> >
> > T o m   M a g u i r e
> >
> >
> > STSM, On Demand Architecture
> >
> >
> > Poughkeepsie, NY  12601
> >
>
>