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

Re: Positions on issue 19

From: Martin Gudgin <marting@develop.com>
Date: Mon, 28 May 2001 14:43:24 +0100
Message-ID: <01c501c0e77c$2bed5930$0300a8c0@greyarea>
To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>, <xml-dist-app@w3.org>
Cc: "Allen Brown" <allenbr@microsoft.com>

----- Original Message -----
From: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
To: <xml-dist-app@w3.org>
Cc: "Allen Brown" <allenbr@microsoft.com>
Sent: Monday, May 28, 2001 1:09 AM
Subject: Positions on issue 19


>
> The following is what I believe is a summary of the discussion we have
> had on issue 19 [1] that says:
>
> The SOAP spec currently does not require any namespace
> for the children elements of the Fault element; namely,
> faultcode, faultstring, detail, and faultactor. These
> elements are therefore in the default namespace.

No. These elements are unqualified. Their namespace name is ""

>
> It continues with some discussion on the mailing list (see refs from
> [1]). The fault structure is defined as follows (the latest Rec schema
> for the envelope [2]) where the fault sub-elements "faultcode",
> "faultactor", and "faultstring" are declared as unqualified local
> elements.
>
>   <!-- XMLP/SOAP fault reporting structure -->
>   <complexType name="Fault" final="extension">
>     <sequence>
>    <element name="faultcode" type="qname"/>
>     <element name="faultstring" type="string"/>
>     <element name="faultactor" type="uri-reference" minOccurs="0"/>
>     <element name="detail" type="tns:detail" minOccurs="0"/>
>   </sequence>
>   </complexType>
>
>   <complexType name="detail">
>     <sequence>
>    <any minOccurs="0" maxOccurs="unbounded"/>
>   </sequence>
>     <anyAttribute/>
>   </complexType>
>
> Note that there are different ways of assigning namespaces and so we
> have to differentiate between "having a prefix" and "being qualified".

Having a prefix is a lexical detail. I always think about SOAP from the
Infoset perspective where such lexical details are abtracted away.

> Howeveer, it is not entirely correct to say that these elements are in
> the default namespace.

In fact it is completely incorrect.

> They are unqualified local names and as such
> should not be qualified by a default namespace or otherwise. That is, if
> there is a default namespace then that would have to be unset.

Correct. xmlns="" is your friend...

>
> Anyway, the two positions are as far as I gather:
>
> 1) The SOAP fault elements should be qualified (local names?)
> 2) The SOAP fault elements should be unqualified local names
>
> It is not clear whether 1) calls for global names or whether it calls
> for qualified local names but the intent seems to be to use default
> namespaces.

Default namespace declarations are a lexical detail. Please, everyone, let's
just talk about elements ( and attributes ) being qualified ( have a
namespace name which is *not* "" ) or unqualified ( have a namespace name
which is "" ) and leave the prefixing or otherwise out of it.

The schema for SOAP fault says that the children of the fault element are
unqualified.

>
> Without taking too strong a position I wonder whether it ever makes
> sense to use default namespaces in SOAP. Almost by definition a SOAP
> message will contain multiple namespaces with independent schema
> definitions and without intimate knowledge about the complete message it
> seems likely that a default namespace would step on local elements
> unless being very careful. This is certainly the case if using the SOAP
> section 5 encoding. Also, intermediaries would have to be extremely
> careful if inserting blocks into messages with default namespaces.

Again, provided everyone thinks about things at the Infoset level ( and in
terms of qualified or unqualified ) no problems need occur.

>
> If this is true then it would seem a weak argument for changing things
> from what they are now. In fact, should we discourage the use of default
> namespaces?

Personally, I wish default namespace decls did not exist, so I'm all for
suggesting people don't use them. I've offered to rework ALL the examples in
our spec...

Gudge
Received on Monday, 28 May 2001 09:45:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:01 GMT