- From: Marc Hadley <marc.hadley@sun.com>
- Date: Mon, 12 Nov 2001 18:20:48 +0000
- To: Noah_Mendelsohn@lotus.com
- CC: hugo@w3.org, xml-dist-app@w3.org
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