RE: [wsrf] Reopen Issue WSRF110

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

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
>