Tony's comments on WSRF WS-BaseFaults

["Tony Fletcher" <tony_fletcher@btopenworld.com>]

Title: Message

Dear Martin and others,

 

Having done a search there seems to be a later draft of WS-BaseFaults (draft 04) available 18 Feb 05.  However, access to the document on the OASIS document store is denied - I assume access is currently restricted to members of the TC.  If you are member I wonder if you would be permitted to share a copy with the WS-CAF TC as we are considering adopting it (may also be just finger trouble of course)?

 

Having now had a look through, my personal opinion (I emphasise) is that I think it would be a good idea to a adopt a basis, especially if that basis is widely adopted by other groups.  However, we should be clear that it is only a basis; the draft itself makes it clear that each using application specification has to extend this basis.

 

With that general comment, I have three specific comments with regard to draft 03.

 

1) The Timestamp element is mandatory (it has to be present and can only be present once).  This is made explicit in the schema (although leaving the minoccurs and maxoccurs out would have had the same effect, so obviously this is a deliberate design decision.  However, it seems to me that lack of ability to generate a timestamp, let alone an accurate one might be part of the problem that gave rise to the fault.  Because it is specified to occur exactly once this can not be changed by restriction in an application that uses basefaults.  If it remains mandatory then we will have to define a default value to be used if the system can not generate a 'real' timestamp.  But my preference would be for this element to be made optional.

 

(This second comment may be essentially the same one as Doug was alluding to.)

2)  Section 2 at the bottom of page 5 states:

BaseFault does NOT include open element extensibility. To define an extended fault, you MUST use XML Schema extension to extend the BaseFault type to include additional attributes and/or elements.

 

However, the ErrorCode element is defined to be an extension of anyType (just adding a dialect attribute which is an anyURI) so one could actually use this effectively as an open element extensibility point.

 

3)  There is a section on security considerations, but I wonder why they have not added any wsu:Id(s) as we have at present in WS-CAF?

 

 

Best Regards,

Tony                          

	Tony Fletcher Technical Advisor Choreology Ltd. 68, Lombard Street, London EC3V 9L J   UK
	Phone:	+44 (0) 1473 729537
	Mobile:	+44 (0) 7801 948219
	Fax:	+44 (0) 870 7390077
	Web:	www.choreology.com
Cohesions™
Business transaction management software for application coordination
Work: tony.fletcher@choreology.com
Home: amfletcher@iee.org