W3C home > Mailing lists > Public > xml-dist-app@w3.org > June 2001

Re: Proposed Clarification for Issues 4 and 23

From: christopher ferris <chris.ferris@east.sun.com>
Date: Tue, 05 Jun 2001 07:48:41 -0400
Message-ID: <3B1CC719.D9DCE050@east.sun.com>
To: Noah_Mendelsohn@lotus.com
CC: Marc Hadley <marc.hadley@Sun.COM>, xml-dist-app@w3.org

Noah_Mendelsohn@lotus.com wrote:

> XMLP/SOAP namespaces. It MUST generate a fault (see section 4.4) on
> receipt of messages using >>SOAP/XMLP-defined elements and attributes<<
> that have incorrect namespaces."

How is any processor (SOAP, XML, otherwise) supposed to arrive
at the conclusion that an incorrect namespace has been used for
>>SOAP/XMLP-defined elements and attributes<< ? This seems to suggest
that an element which has a local name of "Envelope" and a namespace
of "http://www.example.com/mynamespace" is somehow invalid? In
fact, it is a wholly distinct and perfectly valid element
that has a qualified name of 
quite possibly with distinct semantic meaning from the SOAP/XMLP

The only case that could be made for a fault would be the presence
of an element or attribute that is assigned to the SOAP/XMLP
namespace that also has a local name that is NOT in the set of names
reserved for SOAP/XMLP element and attribute local names.

e.g. a qname of:
would result in a generated Fault, but a qname of:
would not.

I would also point out that permitting a SOAP/XMLP processor 
to process localnames only (ignoring the namespace) should
be considered harmful. How is that same processor supposed to 
distinguish between like-element/attribute names from different

> What do you think?
> ------------------------------------------------------------------------
> Noah Mendelsohn                                    Voice: 1-617-693-4036
> Lotus Development Corp.                            Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------------
Received on Tuesday, 5 June 2001 08:32:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:36 UTC