Re: Inteaction between message and binding ( was RE: Issue 4: Use of namespace attribute on soap:body )

Hi Gudge,

This has been one of my pet peeves. I am not sure why the original authors
chose to define things this way (perhaps one of them can shed some light
here) but, the spec had been made unnecessarily confusing by providing all
these different twists and variations. We need to try and eliminate all
these confusion areas.

Please see below some specific concerns of mine in <PY>

Regards, Prasad

-------- Original Message --------
Subject: Inteaction between message and binding ( was RE: Issue 4: Use of
namespace attribute on soap:body )
Resent-Date: Wed, 26 Jun 2002 09:28:41 -0400 (EDT)
Resent-From: www-ws-desc@w3.org
Date: Wed, 26 Jun 2002 06:28:08 -0700
From: "Martin Gudgin" <mgudgin@microsoft.com>
To: <www-ws-desc@w3.org>


Talking to myself...

I wrote up the namespace AII issue from the perspective of the binding.
After sending it I did some more thinking and realised that from the
perspective of the message construct things are a bit more complicated
WRT literal/encoded. Note that the observations below do not bear
directly on issue 4, they are just my musings which I present for
discussion.

Here's the deal;

In the message section[1] our spec states;

 'Multiple part elements are used if the message has multiple
logical units'.

This implies that if the message has multiple parts you can put multiple
wsdl:part EIIs with element AIIs inside the message definition. The spec
also states;

 'However, if the message contents are sufficiently complex, then
an alternative syntax may be used to specify the composite structure of
the message using the type system directly. In this usage, only one part
may be specified.'

<PY> I hope it is convenient to use just one part by grouping all different
parts into a single composite structure. However it is not clear to me why
the spec needs to *restrict* it to one part? It is reasonable to permit  > 1
one parts in a message each a composite one (defined via type AII) if the
service specifics make that useful. This is something that should be left to
the designer of the service rather the spec mandating, IMO. I am not sure if
the 'may' in the text 'In this usage, only one part may be specified.' is a
MUST as implied by the English language use of it or if it is in fact a MAY
(as in RFC 2119). I tend to think it is the latter (per section  'Notational
Conventions' of the spec.)
</PY>

This implies that if you use a wsdl:part EII with a type AII you can
only have one wsdl:part inside the message definition. So <wsdl:part
type='' /> allows only one part, <wsdl:part element='' /> allows one or
more parts.

In the soap:body section[2] our spec states;

 'If use is encoded , then each message part references an
abstract type using the type attribute'

This implies multiple wsdl:part EIIs with type AIIs in the message
definition, in direct contradiction to[1].
<PY> If we go with the RFC 2119 interpretation of  'may' in [1] (which I
think we perhaps should) this inconsistency will not exist IMO.</PY>

It also implies that if you are using use='encoded' then you MUST use type
and not element.
<PY>This just violates the separation of abstract and concrete parts of the
WSDL spec. Which can be eliminated by using only 'type' AII and getting rid
of 'element' AII, IMO</PY>


The spec also states;

 'If use is literal , then each part references a concrete schema
definition using either the element or type attribute'

Again this implies multiple wsdl:part EIIs with type AIIs in the message
definition.
<PY> Precisely. I think we should interpret the 'may' in [1] as MAY and fix
the verbiage in the spec to make that clear.</PY>

So it's a bit of a mess. Another implication is that it is VERY
difficult, if not impossible to actually write an 'astract' message
because you need to know whether you are using literal or encoded in
order to construct the message parts correctly.
<PY> Agree 100%. Cleaning up all such confusion areas in the spec should be
something we need accomplish as part of this WG efforts. </PY>

Comments, thoughts, flames etc to the usual address.

Gudge


[1]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/part1/part1.html#IDAWSK
O
[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/part2/wsdl12-part2.html
#_soap_body



-----Original Message-----
From: Martin Gudgin [mailto:mgudgin@microsoft.com]
Sent: 25 June 2002 13:42
To: www-ws-desc@w3.org
Subject: Issue 4: Use of namespace attribute on soap:body



I took an AI at the last telcon to write up Issue 4. Here is that write
up.

The issue is about interaction between the namespace attribute on
soap:body and the targetNamespace of global element declarations in a
schema.

The namespace attribute on the soap:body binding extension element is
only applicable when use='encoded' where it defines the namespace
qualification of the 'wrapper' element for the RPC parameters. The local
name of the wrapper element is defined by the name property of the input
/ output pieces of a portType operation. When use='encoded' the parts
attribute of soap:body refers to parts defined using type='' rather than
element=''. Therefore the interaction does not exist.

Spo I'm not sure there is much of an issue here. We might want to
clarify that if use='literal' then the namespace attribute on soap:body
is not applicable.

Gudge