RE: proposal for eliminating message

Assume the following message definition:

<input name="newReports" typeSystem="<URI for xsd Element>"
type="y:LabReport" minOccurs="0" maxOccurs="unbounded"/>
<input name="oldReports" typeSystem="<URI for xsd Element>"
type="y:LabReport" minOccurs="0" maxOccurs="unbounded"/>

How would I encode this message using literal encoding in SOAP so I can
properly process the message?

Is it the intent that the SOAP message would include a 'newReports' element
containing zero or more y:LabReport parts (hence optional in itself)
followed by an 'oldReports' element? I would assume this would be the case
if we allow the type to be a simple type, which would require an element
wrapper.

In that case could we enforce the part-element to exist whether type refers
to an XSD type or an element?

arkin

  -----Original Message-----
  From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
Behalf Of Prasad Yendluri
  Sent: Saturday, January 18, 2003 11:14 AM
  To: Sanjiva Weerawarana
  Cc: www-ws-desc@w3.org
  Subject: Re: proposal for eliminating message


  This seems pretty reasonable to me.  One change I would like to recommend
is, to split the typeIndicators into two separate attributes so that it is
easily extensible others in future if needed. I.e. instead of having
separate attribute name based the type-system (xsd/MIME etc.), have one
attribute that identifies the type system and the other the value in the
specific type system.

  Instead of the  proposed syntax for type indicators are as follows:

xsdType="qname"
xsdElement="qname"
mimeType="string"

  We would have typeSystem="URI" type="value" (a string which is a QName for
XSD). Do we still need to distinguish between "Type" and "Element" forms?

  With this change,  the example could look as follows:


<portType name="ArchivalService">
   <operation name="StoreRecords">
      <input name="patient" typeSystem="<URI for xsd Type>"
type="x:PatientIdentificationType"/>
      <input name="xrays" typeSystem="<URI for MIME Type>" type="image/jpg"
minOccurs="0" maxOccurs="unbounded"/>
      <input name="reports" typeSystem="<URI for xsd Element>"
type="y:LabReport" minOccurs="0" maxOccurs="unbounded"/>
      <output typeSystem="<URI for xsd Type>" type="anyURI"/>
      <fault  typeSystem="<URI for xsd Type>" type="z:SomethingWrong"/>
   </operation>
   ... other operations ...
</portType>
Will this work?

  Regards, Prasad


  -------- Original Message -------- Subject:  proposal for eliminating
message
        Resent-Date:  Sat, 18 Jan 2003 11:05:52 -0500 (EST)
        Resent-From:  www-ws-desc@w3.org
        Date:  Sat, 18 Jan 2003 02:30:27 -0500
        From:  "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
        To:  <www-ws-desc@w3.org>



Attached is an attempt at a compromise proposal for removing the
 construct.

Sanjiva.

----------------------------------------------------------------------------


    Removing Message
    Sanjiva Weerawarana, January 18, 2003

    1. Introduction
    This document proposes a mechanism for eliminating the <message>
construct from WSDL. The proposed approach attempts at a compromise between
the two extreme positions possible (keep message and replace with just a
single complex type).


    The proposal is written using the shortcut syntax, but can easily be
re-written using the interaction patterns syntax if desired.

    2. Undertanding <message>
    The <message> construct in WSDL was created to address the requirement
that messages often consist of more than one "thing" that needs to be sent.
These "things" are typically related, but not logically part of one large
structure. The most prevalent example is that of some request sent along
with related information (documents). The related information may be sent as
attachments, but that's a question of the message serialization used and not
an issue at the abstract level of service description.

    I believe that the concept of a message consiting of multiple parts is
very real and very much required. However, the use of a new construct,
<message>, to represent such messages have caused much grief.


    As things stand today, the <message> construct defines a message as
consisting of a set of parts, where each part is typed by some type system.
The immediately supported type system is XML Schema, using the attributes
"type" or "element".


    3. Proposal
    The new syntax proposal is as follows:

1 <portType name="ncname">
2    <operation name="ncname">+
3      <input [name="xsd:string"] type-indicator [cardinality-indicator]/>*
4      <output [name="xsd:string"] type-indicator [cardinality-indicator]/>*
5      <fault type-indicator/>*
6    </operation>
7 </portType>Lines 2-6 define an input-output or input-only operation.
Operations have names and indicate zero or more things that may be sent as
input (line 3), zero or more things that the service may generate in
response (line 4) and zero or more fault types, one of which the service may
send instead of a response (line 5). Each "thing" is typed using some type
system and indicates its cardinality. Each "thing" may optionally be named
so as to allow bindings to be selective about which parts go where in
building a wire format. Note that at least one input or output must be
specified and that the lack of any inputs indicates that the


    How does one specify the type? WSDL 1.1 supported XML Schema types and
elements and left room for other type systems. I propose WSDL 1.2 explicitly
support XML Schema and the MIME type systems. The proposed syntaxes for type
indicators are as follows:


xsdType="qname"
xsdElement="qname"
mimeType="string"
  Thus, any input, output or fault could be typed using XML Schema or MIME.
Other type systems will be supported via extensibility.


    How does one specify the cardinality? One of the issues we've had with
the <message> construct is that it did not allow one to specify that a part
is optional, or that a part may repeat and so on. While it is not desired to
re-invent XML Schema's mechanisms for indicating cardinality, it is indeed
useful to be able assert some of that information. I propose we select a
compromise position whereby we allow any input, output or fault to indicate
its "minOccurs" and "maxOccurs" cardinality, where minOccurs and maxOccurs
are defined as per XML Schema. The proposed syntax is as follows:

<(input|output|fault) [name="xsd:string"] type-indicator [minOccurs="int"]
[maxOccurs="int"]/>As with XML Schema, the default value for minOccurs and
maxOccurs will be 1 and "unbounded" is used to indicate infinity.

    4. Relationship to Interaction Patterns Proposal
    The interaction patterns proposal has been updated to reflect the impact
of this proposal and is sent along with this (see
interaction-patterns-jan-18-2003.html).

    5. Example
    Consider a medical records archival service. One of the operations
offered could be to store a patient record as a patient is being discharged
from a hospital. The information to be sent to the archival service includes
the patient identification information, copies of all of the X-Ray images
that were taken during the hospital stay, and copies of all laboratory
reports. The service wil return an identification token to be used when
requesting the data at a later time.

    The following portType fragment illustrates how this functionality will
be expressed using the proposed new syntax:


<portType name="ArchivalService">
   <operation name="StoreRecords">
      <input name="patient" xsdType="x:PatientIdentificationType"/>
      <input name="xrays" mimeType="image/jpg" minOccurs="0"
maxOccurs="unbounded"/>
      <input name="reports" xsdElement="y:LabReport" minOccurs="0"
maxOccurs="unbounded"/>
      <output xsdType="anyURI"/>
      <fault xsdType="z:SomethingWrong"/>
   </operation>
   ... other operations ...
</portType>