Re: Issue 135 - Re: discarding incorrect namespaces

Noah_Mendelsohn@lotus.com wrote:
> Shouldn't we clarify that treating NS mismatch as version errors applies 
> only to the particular constructs of our specification?  If I send you a 
> header entry with a bad NS, that might very well be a mustUnderstand 
> error, for example.
>
I agree.

> I think we should be absolutely unambiguous as to 
> where a NS mismatch is a version error. 
> 
Also agreed.

> More specifically, we should be clear on at least the following (presuming 
> SOAP-ENV is the correct SOAP 1.2 NS prefix):
> 
> 1.      <SOAP-ENV: Envelope> <!-- presumably OK>
> 
> 2.      <OTHERNS:Envelope> <!-- version mismatch>
> 
> 3.      (as root of message infoset):
>         <OTHERNS:EmployeeRecord> <!-- version mismatch or misformed SOAP 
> header -->
> 
> 4.      <SOAP-ENV: Envelope2> <!-- good NS, version mismatch anyway?>
> 
> Similarly for Body, Header, Encoding values, etc.  We need to be careful 
> to cover any case that a reader of the spec might _think_ is a ns 
> mismatch, I think.  Thank you. 
> 
I guess this boils down to the question of whether the localname of the 
root of the message infoset is significant when the namespace is not the 
SOAP 1.2 namespace. I would suggest that the envelope namespace 
signifies "this is a SOAP 1.2 message" and that a different namespace 
signifies that it isn't. Thus 2 and 3 should be treated as version 
errors whereas 4 would be a "Client" fault.

Comments ?

Regards,
Marc.

-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.

Received on Monday, 12 November 2001 13:23:01 UTC