RE: proposal for eliminating message

This is nothing to do with XSD. My point is that XML ALREADY has a
mechanism for changing the meaning of a local name based on a URI. That
mechanism is described in Namespaces in XML[1]
 
Gudge
 
[1] http://www.w3.org/TR/REC-xml-names/ 

	-----Original Message-----
	From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] 
	Sent: 20 January 2003 03:03
	To: Martin Gudgin; Prasad Yendluri
	Cc: www-ws-desc@w3.org
	Subject: Re: proposal for eliminating message
	
	
	Are you referring to XSD's inability to handle co-occurence
	constraints for attribtues? 
	 
	We're designing a language using XML as its syntax. We can
choose
	to use whatever legal syntactic constructs as seem appropriate
	and comfortable to us. If such constructs cannot be XSD
validated,
	well, tough.
	 
	In this particular case I also prefer that we should spec out
	whatever attributes for the type systems we choose to support
	rather than the approach that Prasad prefers. However, I don't
	see anything fundamentally wrong with his approach; its just
	a different way ..
	 
	Sanjiva.

		----- Original Message ----- 
		From: Martin Gudgin <mailto:mgudgin@microsoft.com>  
		To: Prasad Yendluri <mailto:pyendluri@webMethods.com>  ;
Sanjiva Weerawarana <mailto:sanjiva@watson.ibm.com>  
		Cc: www-ws-desc@w3.org 
		Sent: Monday, January 20, 2003 1:10 AM
		Subject: 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" <sanjiva@watson.ibm.com>
<mailto:sanjiva@watson.ibm.com> 	
To: 	<www-ws-desc@w3.org> <mailto: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>