On Apr 28, Heiko Ludwig loaded a tape reading:
I guess the example templates in the fall draft are all incomplete, hence difficult to assess. I don't understand what you mean with the "wrapping element". XPath has this selection expression that hopefully matches one or more parts of the name, context or terms section, which are supposed to be present in the template. Agreement clients can then fill in any structure compliant with constraints.
Let me try to rephrase my question as two separate questions. First, regarding XPath, I may not be good enough with it to be understanding the examples. Are XPath expressions always "rooted" or can they match arbitrary sub-structures (analogous to anchored versus non-anchored regular expression matching)? I am guessing from your comment that they are unanchored. If they can be anchored, do we say something strong enough about what the root is for anchored matches, e.g. that it is rooted at the wsag:template element or at the client's corresponding wsag:offer element? My other question about structural constraints was echoed in multiple questions but not directly enough to be clear. I had always expected (and intented, in my early contributions to this spec) that templates were going to be the mechanism to "rescue" us from the open content model. However, I do not see how this is the case at all. I would like to be able to: A. Restrict the domain-specific service description term type(s) which MAY appear in an offer from the provider's point of view. B. Restrict the nesting/composition of service description terms, e.g. limit the form of logical compositions the provider will process. Maybe this is coupled with (A) in a syntax language or with your proposal below about using compositors in templates? C. Restrict the nesting/composition of open content extensions which MAY appear in any particular service description term open content "slot". D. Express dependencies/implications such as if X appears, then so MUST Y. E. Cover variable-cardinality scenarios for the above. At present, I do not understand which of these (or other) purposes is being addressed by the agreement syntax in the template nor by the constraints syntax. If a term shows up in the agreement syntax part, MUST that term show up in offers based on the template? MAY more than one instance of the term show up? MAY other terms show up which are not listed here? Can constraints using xsd:restriction express restrictions on the nested element structure, or just on simple type fields? If xsd:restriction is powerful enough, is that a good idea? MUST there be a structure in the offer that matches each constraint in the template? Or MAY completely unconstrained structures appear? This is what I meant before by what is the matching rule. A much more complete semantics must be provided, e.g. turn the template into a logical constraint system which is applied to an offer to see if it "satisfies" the template or not.
I didn't quite understand you issue. Related to this: We might want to introduce a description of alternatives of terms that apply in the constraint section, probably also using the WS-Policy compositors.
I would like to hear more about this to understand what you are proposing and how it fits in w/ the above questions.
Absolutely not. I think they are central to most but not the most trivial scenarios. And actually, we are not in such a bad shape and they work well, according to our experience.
I agree they are important. I was only trying to be fair and admit that I do not quite understand the scope of what is "there" nor the magnitude of the can of worms I am opening. :-) I do think we need to make drastic repairs to the presentation even if the current technical solution is adequate. I find it worrisome if I cannot figure out what the spec is actually saying, since I thought I understood the template problem before! Another concern for me is that there needs to be tractable ways to normalize or query templates. For this stuff to really fly, we need to assume a discovery system will aggregate templates from many different providers and provide a meaningful and efficient way for a prospective client to search for templates that have the right structural properties! There is a tension and the offer/template model needs to "recurse" so to speak and not just end up with an "insert oracle here" layer in the architecture. karl -- Karl Czajkowski karlcz@univa.com