[graap-wg] Templates too restrictive?

[Karl Czajkowski]

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 at univa.com