Re: Progressive Concreteness of Choreography binding

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"

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.

Can you show me how the abstract "PurchaseOrder" described above will look 
like in WSDL ?

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
>

Received on Thursday, 3 April 2003 02:24:26 UTC