Re: Progressive Concreteness of Choreography binding

I have some discomfort with not only separating out message content 
extraction from the choreograpy, but adding an extra level of 
indirection, namely, that the original message content may go through a 
transformation, prior to extraction of a message part.

For me at least Ricky's orignal use case
>> 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"
> 

is an exotic one. It goes back to the question of whether you can really 
write a single choreography definition that works with widely differing 
message types. At some point in the range of possible variation of 
messages, IMO you get to a case where the choreography itself has to be 
different. E.g. suppose some PO formats always have a shipping address, 
and some make reference to a prior commercial agreement that contains 
the shipping address (I'm making this up). Then even XSLT + XPath 
doesn't yield you the shipping address from the latter type of message.

N.b. I'm not necessarily opposed to this level of complexity if it's 
really necessary, and hopefully it can be made unburdensome to someone 
who doesn't need it.

--Jon

Ricky Ho wrote:
> 
> 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 13:23:26 UTC