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