W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

Re: Straw-man Proposal for our mission statement

From: Carol McDonald <carol.mcdonald@sun.com>
Date: Thu, 29 May 2003 15:10:06 -0400
Message-ID: <3ED65B0E.4090401@sun.com>
To: Steve Ross-Talbot <steve@enigmatec.net>
CC: Jean-Jacques Dubray <jjd@eigner.com>, "'Yaron Y. Goland'" <ygoland@bea.com>, "'Assaf Arkin'" <arkin@intalio.com>, "'Burdett, David'" <david.burdett@commerceone.com>, Daniel_Austin@grainger.com, public-ws-chor@w3.org

+1

Steve Ross-Talbot wrote:

>
> +1 from me too.
>
> Steve T
>
> On Wednesday, May 28, 2003, at 07:27  am, Jean-Jacques Dubray wrote:
>
>>
>> +1
>>
>> Jean-Jacques
>>
>>
>>
>>>> -----Original Message-----
>>>> From: Yaron Y. Goland [mailto:ygoland@bea.com]
>>>> Sent: Dienstag, 27. Mai 2003 21:12
>>>> To: Jean-Jacques Dubray; 'Assaf Arkin'
>>>> Cc: 'Burdett, David'; Daniel_Austin@grainger.com;
>>>
>> public-ws-chor@w3.org
>>
>>>> Subject: RE: Straw-man Proposal for our mission statement
>>>>
>>>> Based on this thread I would like to put forward a proposal to the
>>>
>> group
>>
>>>> for
>>>> a set of requirements that I hope can bring this thread to a
>>>
>> successful
>>
>>>> conclusion:
>>>>
>>>> "The WS-Chor specification MUST NOT adopt a design that prevents it
>>>
>> from
>>
>>>> taking full advantage of all features in WSDL 1.2. The WS-Chor
>>>> specification
>>>> MAY adopt a design that enables the use of alternative message
>>>
>> description
>>
>>>> than WSDL 1.2 where and when the working group decides this is
>>>
>> appropriate
>>
>>>> and does not conflict with any other requirements."
>>>>
>>>> I would then propose that we table this issue until we finish with the
>>>> requirements and start doing design so we can look at exactly what an
>>>> abstract design would require and then decide if we want to try it.
>>>>
>>>>         Yaron
>>>>
>>>>> -----Original Message-----
>>>>> From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
>>>>> Sent: Wednesday, May 21, 2003 1:16 PM
>>>>> To: 'Yaron Y. Goland'; 'Assaf Arkin'; 'Jean-Jacques Dubray'
>>>>> Cc: 'Burdett, David'; Daniel_Austin@grainger.com;
>>>>
>> public-ws-chor@w3.org
>>
>>>>> Subject: RE: Straw-man Proposal for our mission statement
>>>>>
>>>>>
>>>>> The cost of abstraction is way overestimated here. The abstraction
>>>>
>> is
>>
>>>>> already built, it is called a message and a message exchange
>>>>
>> pattern.
>>
>>>>> Now we have the choice to directly use the WSDL message definition
>>>>
>> or
>>
>>>>> rather define something like:
>>>>>
>>>>> <message name="ProcessPO">
>>>>> <message name="AckPO>
>>>>> <mep name="ProcessPO">
>>>>>
>>>>> <binding message="ProcessPO" type="WSDL" version="1.2">
>>>>>         <portType="">
>>>>> </binding>
>>>>> <binding MEP="ProcessPO" type="ebXML" version="2.0>
>>>>>     <BPSS
>>>>> URI=http://oasis.org/bunchOfStandardsCollabs/aPOCollaboration">
>>>>>     <businessTransactionActivity name="ProcessPO>
>>>>> </binding>
>>>>> <binding message="AckPO" type="PlainOldFax" >
>>>>>     <fax number="555-1234"/>
>>>>> </binding>
>>>>>
>>>>> so please, let's reasonable on our assertions.
>>>>>
>>>>> I am currently on travel in beautiful Berlin, with limited email and
>>>>
>> web
>>
>>>>> access. So I will respond more thoroughly to the emails this
>>>>
>> week-end.
>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> JJ-
>>>>>
>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Yaron Y. Goland [mailto:ygoland@bea.com]
>>>>>>> Sent: Montag, 19. Mai 2003 18:50
>>>>>>> To: Assaf Arkin; Jean-Jacques Dubray
>>>>>>> Cc: 'Burdett, David'; Daniel_Austin@grainger.com;
>>>>>>
>>>>> public-ws-chor@w3.org
>>>>>
>>>>>>> Subject: RE: Straw-man Proposal for our mission statement
>>>>>>>
>>>>>>> +1 on tying to WSDL and +1 on Asaf's point that there is a cost to
>>>>>>> abstraction. The only way to 'abstract' away dependency on
>>>>>>
>> something
>>
>>>>> is to
>>>>>
>>>>>>> completely re-invent the thing being depended on and then define
>>>>>>
>> how
>>
>>>>> your
>>>>>
>>>>>>> re-invention maps to the original. This is an extremely expensive
>>>>>>
>>>>> process
>>>>>
>>>>>>> that causes significant harm to interoperability and should only
>>>>>>
>> be
>>
>>>>>>> undertaken when there is no other choice. The 'abstractions'
>>>>>>
>>>>> introduced
>>>>>
>>>>>>> between WSDL and SOAP have caused so much interoperability pain
>>>>>>
>> that
>>
>>>>> two
>>>>>
>>>>>>> different organizations had to be formed to sort out the resulting
>>>>>>
>>>>> mess.
>>>>>
>>>>>>> What we need is a little less abstraction and a lot more
>>>>>>
>>>>> interoperability.
>>>>>
>>>>>>>
>>>>>>>         Yaron
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: public-ws-chor-request@w3.org
>>>>>>>> [mailto:public-ws-chor-request@w3.org]On Behalf Of Assaf Arkin
>>>>>>>> Sent: Monday, May 12, 2003 9:30 PM
>>>>>>>> To: Jean-Jacques Dubray
>>>>>>>> Cc: 'Burdett, David'; Daniel_Austin@grainger.com;
>>>>>>>
>>>>> public-ws-chor@w3.org
>>>>>
>>>>>>>> Subject: Re: Straw-man Proposal for our mission statement
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Jean-Jacques Dubray wrote:
>>>>>>>>
>>>>>>>>> I don't understand your argument, why won't you get everything
>>>>>>>>
>> for
>>
>>>>> free
>>>>>
>>>>>>>>> as long as you have a binding to WSDL whether it is direct or
>>>>>>>>
>> let's
>>
>>>>> say
>>>>>
>>>>>>>>> indirect for the lack of a better word. The advantage of the
>>>>>>>>
>> later
>>
>>>>> is
>>>>>
>>>>>>>>> that in addition of getting everything the ws-arch has to
>>>>>>>>
>> offer,
>>
>>>>> you
>>>>>
>>>>>>> can
>>>>>>>
>>>>>>>>> also re-use the formalism of ws-chor for other technologies.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I just don't see those other technologies as being interesting
>>>>>>>
>>>>> that's
>>>>>
>>>>>>>> all. My personal opinion. In a W3C working group I would prefer
>>>>>>>
>> to
>>
>>>>> pick
>>>>>
>>>>>>>> all the relevant technologies that the W3C maps out as
>>>>>>>
>> interesting
>>
>>>>> as
>>>>>
>>>>>>>> part of the WSA. So far I've only heard of WSDL. If it boils
>>>>>>>
>> down to
>>
>>>>> one
>>>>>
>>>>>>>> technology and that makes my life easier, all the better. What
>>>>>>>
>> other
>>
>>>>>>>> technologies do you suggest we look into?
>>>>>>>>
>>>>>>>>> Having a "binding" framework that relates ws-chor to WSDL
>>>>>>>>
>> garanties
>>
>>>>>>> that
>>>>>>>
>>>>>>>>> the design of ws-chor is now decoupled from the evolution of
>>>>>>>>
>> WSDL,
>>
>>>>> we
>>>>>
>>>>>>>>> would only change the binding not the core choreography
>>>>>>>>
>> language.
>>
>>>>>>>>>
>>>>>>>>> We can clearly see the limitations of a tight coupling between
>>>>>>>>
>> BPML
>>
>>>>> or
>>>>>
>>>>>>>>> BPEL and web services, now that WSDL is shifting from
>>>>>>>>
>> operations to
>>
>>>>>>>>> MEPs, one has to adjust the corresponding specs.
>>>>>>>>>
>>>>>>>> Here is how I understand it. Correct me if I'm wrong.
>>>>>>>>
>>>>>>>> Option 1: based on WSDL
>>>>>>>>
>>>>>>>> Can't use other technologies. Need to be updated when WSDL gets
>>>>>>>
>>>>> updated.
>>>>>
>>>>>>>>
>>>>>>>> Option 2: abstacted with binding to WSDL
>>>>>>>>
>>>>>>>> Can use other technologies. Needs to be updated when WSDL gets
>>>>>>>
>>>>> updated.
>>>>>
>>>>>>>> Extra level of indirection.
>>>>>>>>
>>>>>>>> I think it's obvious why I would prefer no#1, but just for the
>>>>>>>
>> sake
>>
>>>>> of
>>>>>
>>>>>>>> being verbose.
>>>>>>>>
>>>>>>>> Either way if I use some normative specification and that
>>>>>>>
>>>>> specification
>>>>>
>>>>>>>> evolves I would want to use the new version, be it WSDL, XSDL,
>>>>>>>
>>>>> XPath,
>>>>>
>>>>>>>> whatever. So either way we need to update the specification. It
>>>>>>>
>> may
>>
>>>>>>>> affect language section 4 or it may affect binding appendix A,
>>>>>>>
>> but
>>
>>>>>>>> that's all the same. I don't see a real big differentiaor
>>>>>>>
>> between 1
>>
>>>>> and
>>>>>
>>>>>>>> 2 to suggest one is better than the other. And as you guess I've
>>>>>>>
>>>>> already
>>>>>
>>>>>>>> planned for it so I know what it entails and it doesn't seem
>>>>>>>
>> like a
>>
>>>>> big
>>>>>
>>>>>>>> issue to me.
>>>>>>>>
>>>>>>>> Option 2 is simply more complicated to support and require
>>>>>>>
>> invention
>>
>>>>> of
>>>>>
>>>>>>>> an abstract layer and invention of a binding layer which makes
>>>>>>>
>> the
>>
>>>>>>>> specification, implementations, interoperability, RI, etc more
>>>>>>>> complicated. That's good if it actually buys you anything. What
>>>>>>>
>> does
>>
>>>>> it
>>>>>
>>>>>>>> buy you?
>>>>>>>>
>>>>>>>> I've heard before the argument that if we only wrote the spec to
>>>>>>>
>> not
>>
>>>>> so
>>>>>
>>>>>>>> directly rely on WSDL we could also use IDL. Well, by the time
>>>>>>>
>> we go
>>
>>>>> to
>>>>>
>>>>>>>> finish the spec the problem was already taken care of and you
>>>>>>>
>> have
>>
>>>>>>>> IDL-WSDL mapping that's well defined and readily available. It
>>>>>>>
>> was
>>
>>>>> in my
>>>>>
>>>>>>>> opinion - then and now - a waste of time to consider anything
>>>>>>>
>> other
>>
>>>>> than
>>>>>
>>>>>>>> WSDL.
>>>>>>>>
>>>>>>>> We've talked about simplifying the language which as I read it
>>>>>>>
>> means
>>
>>>>> do
>>>>>
>>>>>>>> less features now, do the rest later on. I'm going to buy a hat.
>>>>>>>
>> If
>>
>>>>>>>> we're going to have to change the specification because using
>>>>>>>
>> WSDL
>>
>>>>> is no
>>>>>
>>>>>>>> longer the only interesting option before we get around to
>>>>>>>
>> writing a
>>
>>>>> new
>>>>>
>>>>>>>> version of the specification anyway, I'm going to eat it. Wish
>>>>>>>
>> me
>>
>>>>>>> luck ;-)
>>>>>>>
>>>>>>>>
>>>>>>>> arkin
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jean-Jacques Dubray____________________
>>>>>>>>> Chief Architect
>>>>>>>>> Eigner  Precision Lifecycle Management
>>>>>>>>> 200 Fifth Avenue
>>>>>>>>> Waltham, MA 02451
>>>>>>>>> 781-472-6317
>>>>>>>>> jjd@eigner.com
>>>>>>>>> www.eigner.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>
>> This email is confidential and may be protected by legal privilege. 
>> If you are not the intended recipient,  please do not copy or 
>> disclose its content but  delete the email and contact the sender 
>> immediately. Whilst we run antivirus software on all internet emails 
>> we are not liable for any loss or damage. The recipient is advised to 
>> run their own antivirus software.
>>
>
> This email is confidential and may be protected by legal privilege. If 
> you are not the intended recipient,  please do not copy or disclose 
> its content but  delete the email and contact the sender immediately. 
> Whilst we run antivirus software on all internet emails we are not 
> liable for any loss or damage. The recipient is advised to run their 
> own antivirus software.
>
Received on Thursday, 29 May 2003 15:07:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:17 GMT