Re: fault/detail

On Tuesday, July 23, 2002, at 09:44 PM, Martin Gudgin wrote:
>
> We have two namespace URIs;
>
>   http://www.w3.org/2002/06/soap-envelope
>   http://www.w3.org/2002/06/soap-encoding
>
and http://www.w3.org/2002/06/soap-faults. We have *three* 
namespace URIs:

http://www.w3.org/2002/06/soap-envelope
http://www.w3.org/2002/06/soap-encoding
http://www.w3.org/2002/06/soap-faults

and http://www.w3.org/2002/06/soap-upgrade. *Amongst* our 
namespaces are such diverse URIs as:

http://www.w3.org/2002/06/soap-envelope
http://www.w3.org/2002/06/soap-encoding
http://www.w3.org/2002/06/soap-faults
http://www.w3.org/2002/06/soap-upgrade

:-)) (with apologies to Monty Python).

Marc.

PS on a slightly more serious note I think it would be pragmatic to 
combine the envelope, faults and upgrade namespaces but I don't 
think its worth doing another last call for this alone.

>> Custom elements defined by users that are not defined in the
>> SOAP spec should probably be namespace qualified as well, but with a
>> different custom namespace.
>
> If they're children of Header or Body they MUST be namespace 
> qualified and
> the namespace URI cannot be http://www.w3.org/2002/06/soap-envelope
>
> If they are children of Detail then they do not have to be namespace
> qualified. If they are namespace qualified it can be with any 
> namespace URI.
>
>> If elements aren't namespace qualified,
>> they should be consistently so.
>>
>> I specifically object to cases like this example in the Primer:
>>
>> <e:myfaultdetails
>>          xmlns:e="http://travelcompany.example.org/faults" >
>>          <message>Name does not match card number</message>
>>          <errorcode>999</errorcode>
>> </e:myfaultdetails>
>>
>> That should be
>>
>> <e:myfaultdetails
>>          xmlns:e="http://travelcompany.example.org/faults" >
>>          <e:message>Name does not match card number</e:message>
>>          <e:errorcode>999</e:errorcode>
>> </e:myfaultdetails>
>
> IIRC many of us argued this to death on XML-DEV about a year ago. 
> I wasn't
> convinced then and I don't think I am now either.
>
> Gudge
>
>
>
--
Marc Hadley <marc.hadley@sun.com>
XML Technology Center, Sun Microsystems.