I have a simple question: do these hierarchical fault codes have any
well-defined semantics? Could I express a stack trace with them? Could I
also just present the same error in 5 languages? Could I express failure
with possibility for retry vs. failure with no retry? Is there any way
of telling which of these things I chose? It seems to me that this is
quite complex and that, at least, Rich's suggestion of making the first
value element something "official" would help make it manageable in
practice.
FTP and HTTP also have (limited) hierarchical fault codes, but the
semantics are very well-defined. I'm no expert, but this seems to have
worked well in practice. Is this the model? Well, back to lurking..
-- Dan
Rich Salz wrote:
>> <faultcode>
>> <value>soap:Reciever</value>
>> <value xmlns:app='http://example.org/apps' >app:SomeError</value>
>> </faultcode>
>>
>
>>This doesn't imply a hierarchy to me but rather that all the fault codes are
>>of equal 'importance'. But I can see the argument that the order of the
>>siblings determines importance.
>>
>
> Right, it's a slight shift of emphasis.
>
> The sender may now include multiple fault values that provide differing
> levels of specificity or other description. The receiver scans through
> the list looking for a QNAME it understands.
>
> As for schema definition, I'd actually consider tweaking it so that the
> first value element must be from the standard-specificed enumerated list
> of values. Subsequent optional value elements may provide more detail
> for the receiver.
> /r$
>
>