Re: Primer example & ambiguity issue

Hi Mark:

> And this is example 5-5; "doc style and the soap message"
>
> <?xml version='1.0' ?>
> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
>  <env:Body>
> <customerName>Kevin Liu</customerName>
> <checkInDate>2002-09-01</checkInDate>
> <checkOutDate>2002-09-10</checkOutDate>
> <roomType>double</roomType>
> <comments>the customer will be arriving late in the evening</comments>
>  </env:Body>
> </env:Envelope>

Hm - I'm not sure this example is actually valid anymore with our current
design.  In particular, the message="" attribute of <input> and <output> takes
a single QName of a GED.  Thus I'm not sure we support the ability to create
SOAP bodies with multiple top-level children.  IMHO, this is a fine thing, but
we may want to consider the ramifications carefully.

> But in the latter message, there's no operation visible.  What then,
> would success or failure refer to, and where would that symbol be
> located?  Or is it implicit in a spec someplace?  If so, where?

Heh.  We had this very discussion at the F2F.  Without the "uniqueness on the
wire" constraint of a unique GED per operation, you need some other as yet
undefined mechanism for looking at a given message and determining which
operation is relevant.  The group bucked pretty hard against an enforced
uniqueness constraint, so Umit and I are scheduled to write up a proposal for
an abstract Feature description which passes operation information over the
wire.  This Feature could be implemented in a variety of ways, such as a) using
the RPC style, b) using soapAction, c) using a well-defined SOAP module to put
an identifier in a header, etc.  The proposal may include wording to the effect
that this feature would be, by default, required - which would mean that unless
something in the description implemented the feature, the document would be
invalid.

If you guarantee that there is some way of identifying the operation, you
enable server-side skeleton builders to successfully build a framework for the
service which knows how to dispatch correctly.

> Also, where's the "document style" style?  WSDL 2.0 only defines RPC,
> and get/set.

The "document style" is the default (i.e. no style), and rather than making any
specific claims about programming model hinting, it implies nothing in
particular except that the messages infosets will look a particular way.  The
other styles are there to hint that particular programming models were in use
when this WSDL was generated, and that processors may wish to utilize that
information.

--Glen

Received on Friday, 14 November 2003 16:41:25 UTC