XOM API for Processing XML with Java

[Steve Loughran <steve.loughran AT gmail.com>]

On 7/7/05, Elliotte Harold <elharo AT metalab.unc.edu> wrote:
> Steve Loughran wrote:
> 
> > Its why the pragmatism of REST has an advantage -it is
> > content-agnostic. Even so, I'd like to see the rest equivalent of
> > SOAPFaults; a well known XML document to return on an error, one that
> > can be easily turned into human readable content by the browser/a
> > standard XSLT, but yet which provides more machine readable. info than
> > just '500',
> 
> Why not place something in the body of the HTTP 500 response? The HTTP
> 1.1 spec states:
> 
>     Except when responding to a HEAD request, the
>     server SHOULD include an entity containing an explanation of the
>     error situation, and whether it is a temporary or permanent
>     condition. User agents SHOULD display any included entity to the
>     user. These response codes are applicable to any request method.
> 
> This might as well be XML + XSLT.
> 

yes indeed. all we need is a bit of a standard of the payload of that
response. The 500 message is the obvious location.

But SOAPFault not the obvious payload. Whoever did that bit of the
spec didnt fully understand namespaces, to the extent that the
faultcode/faultstring/faultdetail elements under <soap:Fault> have to
be local, not in the soap ns.