Re: Progressive Concreteness of Choreography binding

Assaf,

Thinking more about the XSL/T approach.  I think the AbstractPO doesn't 
need to be xsd:Any.  It can just be the following ...

<complexType name="AbstractPO">
         <element name="shippingAddress" type="Address"/>
         <element name="totalAmount" type="xsd:float"/>
</complexType>

Because you can use a handcode XSL/T to transform any concrete PO (even 
EDI) to the above structure.

Rgds, Ricky


At 12:00 AM 4/3/2003 -0800, Assaf Arkin wrote:

>Ricky Ho wrote:
>
>>Assaf,
>>
>>I agree with your principle.  But I just don't see how "abstract" WSDL 
>>can be.  Let me give an example.
>>
>>Lets say I define a choreography to handle PurchaseOrder message.  I 
>>don't want to constraint the message structure of this message as long as 
>>it fulfill the following ...
>>
>>1) Somewhere in this "PurchaseOrder" message will contain a 
>>"shippingAddress" which can be mapped to complex type "Address".
>>- But I don't want to constraint the element name of this 
>>"shippingAddress", (e.g. the element name can be "shipAddr", "shipTo", 
>>"sendTo" ... etc.)
>>- I also don't want to constraint such an "shippingAddress" element to 
>>have the exact complex type "Address".  The type can be anything as long 
>>as it can be transformed (via XSL/T) into type "Address"
>
>Are we talking abstract or over-the-wire?
>
>If we're talking abstract I don't see what it brings to the table. Find 
>some common name to use, agree on that name and use it. If you're looking 
>for interoperating then you have to agree on using the same name. Whether 
>you call it shipAddress or shipTo, you have to figure out some name to 
>distinguish from billAddress or billTo.
>
>If we're talking about over-the-wire, use whatever you want. Because you 
>can always XSLT transform. Let's say the abstract message uses the name 
>shippingAddress. You can XSLT transform to/from an over-the-wire message 
>that uses shipTo, sendTo, etc and places that element anywhere else in the 
>document.
>
>So you do get:
>
>a) a declaration of what is in the message using some name everyone can 
>reference
>b) abstraction to use any number of different over-the-wire messages
>c) and you can use XSTL to transform from one to the other
>
>>
>>2) Somewhere in this "PurchaseOrder" message will contain a "totalAmount" 
>>which is type "float"
>>- Again, I don't want to constraint the element name of this "totalAmount".
>>- In fact, it doesn't even have to be an element.  It can be an attribute.
>
>Or something you can calculate e.g. by multiplying quantity by price and 
>then summing it up.
>
>
>>Can you show me how the abstract "PurchaseOrder" described above will 
>>look like in WSDL ?
>
>PurchaseOrder of type xsd:anyType
>
>Essentially you want to create a situation where the seller may put some 
>value in shipTo and the buyer may expect to find that value under 
>shipAddr. xsd:anyType gives you that form of abstraction. Of course, it 
>doesn't give you any interoperability because buyers and sellers can't 
>really decide where to put what information. Or alternatively, you have to 
>create too many transformations so you can't just pick a buyer/seller and 
>use their service, you have to first decide on a transformation to use.
>
>So xsd:anyType is a possibilty if you want the ultimate abstraction. You 
>got that. But it also points to the limitation of ultimate abstraction as 
>a means to hinder interoperability or increase integration complexity, 
>whichever way you want to look at it.
>
>Comments?
>
>arkin
>
>>
>>Best regards,
>>Ricky
>>
>>
>>>Conceptually I don't see why this problem would exist. You can define 
>>>abstract messages with WSDL, and you can define abstract types with XSDL 
>>>and then extend them in various ways (derivation, any content, 
>>>substitution, etc).  So my gut instict is that it's going to be a wild 
>>>goose chase to work out a solution to a problem that does not exist. I 
>>>would be more interested to see a specific use case which cannot be 
>>>solved using these technologies and then try to tackle, rather then 
>>>spend much time trying to work out a problem that can't be identified.
>>>
>>>I'm not saying WSDL and XSDL are perfect. We know there are a lot of 
>>>issues with WSDL 1.1 particularly in relation to abstraction (e.g. 
>>>inheritence is something that needs to be solved). The question is: are 
>>>these issues that cannot possibly solved in the framework of WSDL and 
>>>XSDL? Or are these things that can be solved. In the later case, should 
>>>every specification that depends on WSDL/XSDL work around these 
>>>limitations at the risk of further complication, or can we ask these 
>>>working group to tackle specific problems we have identified.
>>>
>>>My personal opinion is that there is no conceptual issue that prevents 
>>>WSDL from solving these problems, and further, that these problems are 
>>>not specific to choreography. Abstraction is not something you care 
>>>about only because you are doing choreography. Abstraction is important 
>>>in a variety of other cases. So that's something the WSD working group 
>>>need to address, and if we can identify a real use case we can give tham 
>>>that information as an input.
>>>
>>>Otherwise, we're just spinning a lot of wheels and not getting any work 
>>>done.
>>>
>>>arkin
>>>
>>>>
>>>>Rgds, Ricky
>>>
>
>
>--
>"Those who can, do; those who can't, make screenshots"
>
>----------------------------------------------------------------------
>Assaf Arkin                                          arkin@intalio.com
>Intalio Inc.                                           www.intalio.com
>The Business Process Management Company                 (650) 577 4700
>
>
>This message is intended only for the use of the Addressee and
>may contain information that is PRIVILEGED and CONFIDENTIAL.
>If you are not the intended recipient, dissemination of this
>communication is prohibited. If you have received this communication
>in error, please erase all copies of the message and its attachments
>and notify us immediately.
>
>

Received on Thursday, 3 April 2003 10:27:50 UTC