RE: proposal for eliminating message

What is with this recent penchant for mangaling XML syntax with URIs?
Since when has using the value of an attriute of type xs:anyURI to
change the meaning of some other attribute been the way we do things?
Oh, wait a minute, isn't that how XML namespaces work? The right way to
do this is to define attributes for stuff we bake into our core spec (
which at the moment I think is just XML Schema ) and allow other type
systems to use qualified attributes to do their thing, just as they do
with part today.
 
The same comments apply to the inteaction proposal.
 
Gudge

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@webMethods.com] 
Sent: 18 January 2003 19:14
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"  <mailto:sanjiva@watson.ibm.com>
<sanjiva@watson.ibm.com>	
To: 	 <mailto:www-ws-desc@w3.org> <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>