- From: Assaf Arkin <arkin@intalio.com>
- Date: Thu, 03 Apr 2003 10:57:21 -0800
- To: Ricky Ho <riho@cisco.com>
- CC: public-ws-chor@w3.org
> > I am talking about define an "abstract" complex type that fulfill the > 2 constraints that I specify here while NOT be able to allow various > very different over-the-wire format be able to map to it. Can you give me a specific example. The one you gave is easily and efficiently solvable using XSL/T or even XQuery. Is there something you can't solve using existing technologies to require the additional layer? > The XSL/T here is equivalent to my separated "Implementation > Binding". I agree that the XSL/T can transform ANY message format to > our required abstract message. In this case, the value of the extra > level of indirection is to provide more precise mapping information so > that you don't need to handcode the XSL/T. If the XSL/T is used to transform the message from its abstract format to the implementation format, that's an implementation issue that is not important for anyone to know. If the XSL/T is used to transform the message from its abstract format to the over-the-wire format, that's a protocol binding issue, so it belongs in the protocol layer. Since you want to express the choreography in abstract term, you don't want to depend on a particular encoding. So you want to express properties in terms of the abstract message. Since you can transform from over-the-wire/implementation to abstract you can determine these values after transformation. So I don't see what the level of indirection would buy you. If anything, it won't allow you to use the choreography. If I use n services all of which support the same abstract format but insist on using some other format internally, I have to understand all these various implementation schemas. That's not useful. And if it's all about understanding these schemas in terms of abstract messages (because transformations are given), can't we just express everything in terms of abstract message to begin with? >>> 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. > > > Exactly. So how can I specify whether the XPATH should be > "//totalAmount" or "//*/@totalAmount" or "sum(//LineItem/@subtotal)" Look at the abstract message definition. Whatever you send over the wire or handle in the back-end is an expression of the abstract message. And you can transform from one to the other. So instead of looking at all the possible n results of the transformation, just look at the abstract message that is common to all these representations. And write the expression based on that abstract. The abstract will tell you whether to use "//totalAmount" or "//*/@totalAmount" and that will work correctly in all cases. > Are you referring to the on-the-wire message inter-operability ? We > don't get this at the choreography level in either my approach or your > approach. In my approach, the on-the-wire message inter-operability > is provided at the "implementation binding" layer, while in your > approach inter-operability comes from XSL/T transformation. So the > inter-operability issue is addressed anyway, just outside the flow > (ie: Abstract Process) itself. In my approach over-the-write inter-operability comes from the protocol binding. They may be very simple, they may be very complex. They may use XSL/T, or a more complex language, or a simpler language, or some semantic mapping. But the important thing is, it has no effect on the choreography, only on the messaging layer that needs to support a particular protocol. And it's protocol dependent, not implementation dependent. So, if you have n protocols (a small number, do we agree?) and m services (unlimited) and one abstract message, then: - You need to write all expressions exactly once (one abstract message) - You need to write only n protocol bindings (exactly n protocols) - You can use m services n can be something like four (SOAP, EDI, ebXML, RN), while m can be something like a million. Think of the alternative: trying to handle a million services because each service insists on a different way to encode the information. arkin > > I'm not seeing how xsd:anyType express the message need to have a > "shippingAddress" and a "totalAmount" data somewhere. I think my > approach is trying to avoid writing an XPATH because an XPATH always > assume certain message structure regardless of how "abstract" it is. > But I agree that the XSL/T transformation you suggest will work, just > pushing the mapping responsibility to the XSL/T layer. > > 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:58:38 UTC