W3C home > Mailing lists > Public > www-ws-desc@w3.org > January 2003

Re: proposal for eliminating message

From: Prasad Yendluri <pyendluri@webmethods.com>
Date: Wed, 22 Jan 2003 11:00:26 -0800
Message-ID: <3E2EEA4A.9080305@webmethods.com>
To: Martin Gudgin <mgudgin@microsoft.com>
CC: www-ws-desc@w3.org


Martin Gudgin wrote:

> What is with this recent penchant for mangaling XML syntax with URIs?

The use of URIs here was to supply a globally unique value, however a 
string value that is not a URI would work well as well. The intent of 
course is to permit addition of new type systems w/o having to define 
new extensibility elements (attributes). I consider the latter a bad design.

I am not seeing this too different from use of URIs practice in use in 
WSDL already.

E.g. <soap:binding transport="uri"? style="rpc|document"?> where the 
tranport is changeable by changing the value of the tranport URI.
or switching the MEPs via URI  etc..

Regards, Prasad

P.S. For WSDL's sake Relax :)

> 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" <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>
>>
>>
>>
>
Received on Wednesday, 22 January 2003 13:59:27 GMT

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