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
? (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