W3C home > Mailing lists > Public > www-ws-desc@w3.org > March 2004

Re: Proposed resolutions for issues 146 and 150

From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
Date: Wed, 24 Mar 2004 16:42:17 -0800
Message-ID: <40622AE9.7000909@oracle.com>
To: Roberto Chinnici <Roberto.Chinnici@Sun.COM>
Cc: Sanjiva Weerawarana <sanjiva@watson.ibm.com>, Martin Gudgin <mgudgin@microsoft.com>, Jacek Kopecky <jacek.kopecky@systinet.com>, Tom Jordahl <tomj@macromedia.com>, WS Description List <www-ws-desc@w3.org>



Roberto Chinnici wrote:

>
> But then you get back to the pitfall I mentioned earlier, i.e.
> that some bindings will only support one element, making an
> application that tried to pass more than one element inadvertently
> binding-specific.
>
> So if we handle this case at all (we could call it (5)), we should
> do so using extensibility.

+1.

>
> Roberto
>
>
> Sanjiva Weerawarana wrote:
>
>> I'd be ok with saying element="#any" means any number of
>> any elements. That has a natural binding in the SOAP case
>> to "stuff it inside <Body>."
>>
>> Then we can indeed describe any SOAP message.
>>
>> Sanjiva.
>>
>> ----- Original Message -----
>> From: "Martin Gudgin" <mgudgin@microsoft.com>
>> To: "Jacek Kopecky" <jacek.kopecky@systinet.com>; "Tom Jordahl"
>> <tomj@macromedia.com>
>> Cc: "WS Description List" <www-ws-desc@w3.org>
>> Sent: Wednesday, March 24, 2004 5:53 AM
>> Subject: RE: Proposed resolutions for issues 146 and 150
>>
>>
>>
>>> Jacek,
>>>
>>> It seems odd ( to me at least ) that WSDL not allow me to describe
>>> messages that are clearly OK per the SOAP spec.
>>>
>>> Gudge
>>>
>>> -----Original Message-----
>>> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
>>> Behalf Of Jacek Kopecky
>>> Sent: 23 March 2004 06:20
>>> To: Tom Jordahl
>>> Cc: 'WS Description List'
>>> Subject: RE: Proposed resolutions for issues 146 and 150
>>>
>>>
>>> Tom, I originally meant the issue 146 as really allowing anything in 
>>> the
>>> message, but I will have no problem with constraining that to "any
>>> single element", it suits the usecase I have in mind here - a
>>> content-based router endpoint that receives any message.
>>>
>>> This way the spec will be clearer and more consistent and the
>>> restriction to a single element in SOAP Body doesn't seem too bad; 
>>> noone
>>> knows how to handle multiple elements there anyway. 8-)
>>>
>>>                   Jacek Kopecky
>>>
>>>                   Systinet Corporation
>>>                   http://www.systinet.com/
>>>
>>>
>>>
>>>
>>> On Mon, 2004-03-22 at 23:07, Tom Jordahl wrote:
>>>
>>>> I actually never believed we were discussing (4), I had always assumed
>>>
>>>
>>> (3).
>>>
>>>> I am also against the idea that you can get away with sticking
>>>
>>>
>>> *anything* in
>>>
>>>> to the message.  Now I understand why Umit is so worked up. :-)
>>>>
>>>> I propose we clarify the meaning of "#any" to be explicit that we are
>>>> specifying "any element", not "any stuff you want".
>>>>
>>>>
>>>> -- 
>>>> Tom Jordahl
>>>> Macromedia Server Development
>>>>
>>>> -----Original Message-----
>>>> From: Roberto Chinnici [mailto:Roberto.Chinnici@Sun.COM]
>>>> Sent: Monday, March 22, 2004 4:36 PM
>>>> To: Arthur Ryman
>>>> Cc: Sanjiva Weerawarana; Martin Gudgin; Tom Jordahl; WS Description
>>>
>>>
>>> List;
>>>
>>>> www-ws-desc-request@w3.org
>>>> Subject: Re: Proposed resolutions for issues 146 and 150
>>>>
>>>> I find the current syntax nice and readble in three of the four cases:
>>>>
>>>>   1)  element="myns:Foo"
>>>>   2)  element="#none"
>>>>   3)  element="#any" (where "#any" means "any element")
>>>>
>>>> It's the fourth case, i.e.
>>>>   4)  element="#any" (where "#any" means "anything, any kind of
>>>
>>>
>>> content")
>>>
>>>> that is problematic.
>>>>
>>>> I'm actually having second thoughts on conflating (3) and (4).
>>>>
>>>> I think that Umit has a point when she says that by adopting (4) we've
>>>> moved away from an element-based content model representation.
>>>>
>>>> Moreover, given that some bindings might have restrictions on the
>>>> allowable payloads for a message, it seems important to distinguish
>>>> between (3) and (4). Otherwise an application written to the abstract
>>>> layer of WSDL will feel authorized, upon encountering a message
>>>> definition which specified element="#any", to pass arbitrary content
>>>> around, including content of a kind that will be systematically
>>>
>>>
>>> rejected
>>>
>>>> by the binding in use. Then we'd fall back again in the trap of
>>>
>>>
>>> writing
>>>
>>>> applications to a specific binding rather than to the abstract
>>>
>>>
>>> interface.
>>>
>>>> Roberto
>>>>
>>>>
>>>> Arthur Ryman wrote:
>>>>
>>>>> Sanjiva,
>>>>>
>>>>> The attribute @element formerly refered to the QName of an element
>>>>> (GED). However, now it may not refer to an element. In fact, the
>>>>
>>>
>>> message
>>>
>>>>> content might be a simple type, or anything else, including nothing.
>>>>
>>>
>>> So
>>>
>>>>> it is a minor misnomer to call the attribute @element. However, most
>>>>
>>>
>>> of
>>>
>>>>> the time it will refer to an element. Logically, the attribute
>>>>
>>>
>>> describes
>>>
>>>>> the message content, which is often, but not always, an element.
>>>>>
>>>>> Arthur Ryman,
>>>>> Rational Desktop Tools Development
>>>>>
>>>>> phone: +1-905-413-3077, TL 969-3077
>>>>> assistant: +1-905-413-2411, TL 969-2411
>>>>> fax: +1-905-413-4920, TL 969-4920
>>>>> mobile: +1-416-939-5063
>>>>> intranet: http://w3.torolab.ibm.com/DEAB/
>>>>>
>>>>>
>>>>> *"Sanjiva Weerawarana" <sanjiva@watson.ibm.com>*
>>>>> Sent by: www-ws-desc-request@w3.org
>>>>>
>>>>> 03/16/2004 10:02 PM
>>>>>
>>>>>
>>>>> To
>>>>> "Martin Gudgin" <mgudgin@microsoft.com>, "Tom Jordahl"
>>>>> <tomj@macromedia.com>, Arthur Ryman/Toronto/IBM@IBMCA
>>>>> cc
>>>>> "WS Description List" <www-ws-desc@w3.org>
>>>>> Subject
>>>>> Re: Proposed resolutions for issues 146 and 150
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I'm confused .. I thought we're talking about special values to
>>>>> assign to the operation/(input|output)/@element attribute to
>>>>> indicate any content (#any) or no content (#empty).
>>>>>
>>>>> What does this have to do with changing the name of the attribute?
>>>>>
>>>>> Sanjiva.
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Martin Gudgin" <mgudgin@microsoft.com>
>>>>> To: "Tom Jordahl" <tomj@macromedia.com>; "Arthur Ryman"
>>>>
>>>
>>> <ryman@ca.ibm.com>
>>>
>>>>> Cc: "WS Description List" <www-ws-desc@w3.org>
>>>>> Sent: Wednesday, March 17, 2004 1:43 AM
>>>>> Subject: RE: Proposed resolutions for issues 146 and 150
>>>>>
>>>>>
>>>>> Have you implemented it already? ;-)
>>>>>
>>>>> Gudge
>>>>>
>>>>> P.S. I've always thought it mildly amusing to have an attribute
>>>>
>>>
>>> whose
>>>
>>>>> name is element ( or vice versa ) ;-)
>>>>>
>>>>>
>>>>> ________________________________
>>>>>
>>>>> From: www-ws-desc-request@w3.org
>>>>> [mailto:www-ws-desc-request@w3.org] On Behalf Of Tom Jordahl
>>>>> Sent: 16 March 2004 11:01
>>>>> To: 'Arthur Ryman'
>>>>> Cc: 'WS Description List'
>>>>> Subject: RE: Proposed resolutions for issues 146 and 150
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> We just changed the name of this attribute to "element".
>>>>>
>>>>> -1 to changing it AGAIN.
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Tom Jordahl
>>>>> Macromedia Server Development
>>>>>
>>>>> -----Original Message-----
>>>>> From: Arthur Ryman [mailto:ryman@ca.ibm.com]
>>>>> Sent: Tuesday, March 16, 2004 1:05 PM
>>>>> To: Tom Jordahl
>>>>> Cc: 'Jonathan Marsh'; 'WS Description List';
>>>>> www-ws-desc-request@w3.org
>>>>> Subject: RE: Proposed resolutions for issues 146 and 150
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Correction to my note:
>>>>>
>>>>> s/elementReference/element/
>>>>>
>>>>> Same comment applies. It's not an element anymore.
>>>>>
>>>>> Arthur Ryman,
>>>>> Rational Desktop Tools Development
>>>>>
>>>>> phone: +1-905-413-3077, TL 969-3077
>>>>> assistant: +1-905-413-2411, TL 969-2411
>>>>> fax: +1-905-413-4920, TL 969-4920
>>>>> mobile: +1-416-939-5063
>>>>> intranet: http://w3.torolab.ibm.com/DEAB/
>>>>>
>>>>>
>>>>>
>>>>> Tom Jordahl <tomj@macromedia.com>
>>>>> Sent by: www-ws-desc-request@w3.org
>>>>>
>>>>> 03/16/2004 09:30 AM
>>>>>
>>>>> To
>>>>>
>>>>> "'Jonathan Marsh'" <jmarsh@microsoft.com>, "'WS Description List'"
>>>>> <www-ws-desc@w3.org>
>>>>>
>>>>> cc
>>>>>
>>>>>
>>>>>
>>>>> Subject
>>>>>
>>>>> RE: Proposed resolutions for issues 146 and 150
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Jonathan,
>>>>>
>>>>> You meant to say "elementReference is the name of a type so it
>>>>> would NOT appear in the syntax"
>>>>>
>>>>> Right?
>>>>>
>>>>>
>>>>> -- 
>>>>> Tom Jordahl
>>>>> Macromedia Server Development
>>>>> -----Original Message-----
>>>>> From: www-ws-desc-request@w3.org
>>>>> [mailto:www-ws-desc-request@w3.org] On Behalf Of Jonathan Marsh
>>>>> Sent: Monday, March 15, 2004 4:48 PM
>>>>> To: WS Description List
>>>>> Subject: RE: Proposed resolutions for issues 146 and 150
>>>>>
>>>>> elementReference is the name of a type so it would appear in the
>>>>> syntax.  I like messageBody better too.  Or I suppose we could just
>>>>
>>>
>>> get
>>>
>>>>> rid of the reference altogether, right?
>>>>>
>>>>> <xs:attribute name="element" >
>>>>>      <xs:simpleType>
>>>>>              <xs:union memberTypes="xs:QName">
>>>>>                      <xs:simpleType>
>>>>>                              <xs:restriction base="xs:token">
>>>>>                                      <xs:enumeration
>>>>> value="#any" />
>>>>>                                      <xs:enumeration
>>>>> value="#empty" />
>>>>>                              </xs:restriction>
>>>>>                      </xs:simpleType>
>>>>>              </xs:union>
>>>>>      </xs:simpleType>
>>>>> </xs:attribute>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ________________________________
>>>>>
>>>>>
>>>>>
>>>>> From: Arthur Ryman [mailto:ryman@ca.ibm.com]
>>>>> Sent: Monday, March 15, 2004 12:58 PM
>>>>> To: Sanjiva Weerawarana
>>>>> Cc: Jacek Kopecky; Jonathan Marsh; WS Description List;
>>>>> www-ws-desc-request@w3.org
>>>>> Subject: Re: Proposed resolutions for issues 146 and 150
>>>>>
>>>>>
>>>>> Sanjiva,
>>>>>
>>>>> The XML Schema looks fine except for a couple of minor errors.
>>>>> Here's a corrected version:
>>>>>
>>>>>      <xs:attribute name="element" type="elementReference" />
>>>>>
>>>>>      <xs:simpleType name="elementReference">
>>>>>              <xs:union memberTypes="xs:QName">
>>>>>                      <xs:simpleType>
>>>>>                              <xs:restriction base="xs:token">
>>>>>                                      <xs:enumeration
>>>>> value="#any" />
>>>>>                                      <xs:enumeration
>>>>> value="#empty" />
>>>>>                              </xs:restriction>
>>>>>                      </xs:simpleType>
>>>>>              </xs:union>
>>>>>      </xs:simpleType>
>>>>>
>>>>>
>>>>> However, I dislike the name of the attribute, elementReference,
>>>>> since the whole point of introducing it was to allow the case where
>>>>> there is no element reference. How about @messageBody or
>>>>
>>>
>>> @bodyContent
>>>
>>>>> instead?
>>>>>
>>>>> Arthur Ryman,
>>>>> Rational Desktop Tools Development
>>>>>
>>>>> phone: +1-905-413-3077, TL 969-3077
>>>>> assistant: +1-905-413-2411, TL 969-2411
>>>>> fax: +1-905-413-4920, TL 969-4920
>>>>> mobile: +1-416-939-5063
>>>>> intranet: http://w3.torolab.ibm.com/DEAB/
>>>>>
>>>>> "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
>>>>> Sent by: www-ws-desc-request@w3.org
>>>>>
>>>>> 03/11/2004 10:50 PM
>>>>>
>>>>>
>>>>>
>>>>> To
>>>>>
>>>>> "Jacek Kopecky" <jacek.kopecky@systinet.com>, "Jonathan Marsh"
>>>>> <jmarsh@microsoft.com>
>>>>>
>>>>> cc
>>>>>
>>>>> "WS Description List" <www-ws-desc@w3.org>
>>>>>
>>>>> Subject
>>>>>
>>>>> Re: Proposed resolutions for issues 146 and 150
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Looks good to me too .. however I'll let Arthur indicate an IBM
>>>>> position as I can barely spell schiema let alone make value
>>>>> judgements about the goodness of using unions.
>>>>>
>>>>> Sanjiva.
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Jacek Kopecky" <jacek.kopecky@systinet.com>
>>>>> To: "Jonathan Marsh" <jmarsh@microsoft.com>
>>>>> Cc: "WS Description List" <www-ws-desc@w3.org>
>>>>> Sent: Thursday, March 11, 2004 8:58 PM
>>>>> Subject: Re: Proposed resolutions for issues 146 and 150
>>>>>
>>>>>
>>>>> >
>>>>> > I applaud the elegance of this proposal. 8-)
>>>>> > I hope it will be accepted.
>>>>> >
>>>>> > Jacek
>>>>> >
>>>>> > On Wed, 2004-03-10 at 18:55, Jonathan Marsh wrote:
>>>>> > > Issues 146 [.1] and 150 [.2] were inadvertently left off the
>>>>> FTF agenda.
>>>>> > > Sorry my bad.  Here's a simple proposal for addressing these
>>>>> issues,
>>>>> > > assuming we find merit in adding this functionality.
>>>>> > >
>>>>> > > Issue 146 Should WSDL be able to describe an operation with
>>>>> *anything*
>>>>> > > in the message? [.1]
>>>>> > >
>>>>> > > Issue 150 Indicating empty bodies [.2]
>>>>> > >
>>>>> > > When using XML SchemaS, The element attribute points to a
>>>>> QName of a
>>>>> > > GED, preventing either empty bodies, or unconstrained
>>>>> content.  Special
>>>>> > > values of the element attribute could indicate these
>>>>> conditions.
>>>>> > >
>>>>> > > Status quo:
>>>>> > >   <xs:attribute name="element" type="xs:QName"
>>>>> use="optional" />
>>>>> > >
>>>>> > > Proposal:
>>>>> > >   <xs:attribute name="element" type="elementReference"
>>>>> use="optional" />
>>>>> > >
>>>>> > >   <xs:simpleType name="elementReference">
>>>>> > >     <xs:union>
>>>>> > >       <xs:simpleType memberTypes="xs:QName">
>>>>> > >         <xs:restriction base="xs:token">
>>>>> > >           <xs:enumeration value="#any"/>
>>>>> > >           <xs:enumeration value="#empty"/>
>>>>> > >         </xs:restriction>
>>>>> > >       </xs:simpleType>
>>>>> > >     </xs:union>
>>>>> > >   </xs:simpleType>
>>>>> > >
>>>>> > > (I hope I have got that syntax right.  Should be enough to
>>>>> spark
>>>>> > > discussion anyway...)
>>>>> > >
>>>>> > > [.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x146
>>>>> > > [.2] http://www.w3.org/2002/ws/desc/2/06/issues.html#x150
>>>>
>
>

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com
Received on Thursday, 25 March 2004 20:27:09 GMT

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