Dear GRAAP members, Karl and I had some email discussion since the Wednesday phone call to resolve the template issue. We agreed that both of our more complex proposals are not well enough throught through at the moment and it would be best to stick to a minimal solution, going only slightly beyond what we have in the 1 comments round draft: - A template contains an offer prototype and the creation contraints. - Creation constrains contain a set of items, each of which -- has a location as an XPath -- may have a simpleRestriction (as we had it) or a complex type restriction ( because it's easy) or any#other content to be interpreted as constraint in its domain. This gives us a good standard template functionality and enough space for experimental approaches to templates sitting on top of this standard and potentially being included in the next revision of WS-Agreement. Furthermore, the proposal is easy to implement. If you have comments on this speak up now. I will start changing the schema and text of the spec correspondingly next week. Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig@us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/ ----- Forwarded by Heiko Ludwig/Watson/IBM on 07/22/2005 10:29 AM ----- Karl Czajkowski <karlcz@univa.com> 07/21/2005 11:28 PM To Heiko Ludwig/Watson/IBM@IBMUS cc Subject Re: Alternative Approach to Templates and Constraints OK. I also wonder if some experiments might be better off in a separate RP from template, but I think the extension idea below is reasonable for "fine tuning" of the model in some domains. Should the Location be fixed to XPath or handled via extensions, e.g. make the normative idiom something like <wsag:Item> <wsag:Location> <wsagext:XPath>/some/path/string</wsagext:XPath> </Location> ? (I made it wsagext so it could go in an any##other defined in the wsag namespace.) karl On Jul 21, Heiko Ludwig modulated: ...

- We keep the existing model of pointers in XPath. Current content is default. - Constraint in: 1. simpleRestriction, the way we have now. that's our minimum. 2. complexType, because it is the same than simpleRestrictions and one can identify the root any#other for experimenting.

As for the standard, 1 and 2 only apply to existing locations. The location can be interpreted differently otherwise.

This way we can keep our proven model, don't have much extension and implementations can be easily adapted. We also understand the limits. With the additional any#other we are open for whatever comes to our minds.

I hope we can agree on this.

Heiko

-- Karl Czajkowski karlcz@univa.com