[graap-wg] Templates too restrictive?

[Heiko Ludwig]

Comments inline. Heiko

owner-graap-wg at ggf.org wrote on 04/25/2005 02:10:06 AM:

> I am confused by the template mechanism in the draft.  The normative
> text seems inconsistent w/ the Job example and nothing is very clear
> to me.
> 
> 1) Is there a way to express schema-like constraints on the presence
>    or absence of Terms?
> 
>    The main text made me think that a domain-specific term must appear
>    in the Terms section of the template and then be qualified if
>    necessary by CreationConstraints.  Must the offer Terms appear with
>    the same document structure (including document-order) as the
>    template Terms element?  What about optional fields or fields with
>    variable cardinality?
> 
>    The job template example in the appendix shows an empty Terms
>    element in the template and then has CreationConstraints/Item
>    elements which make XPath references as
>    //ServiceDescriptionTerm/someJobThing!  This makes no sense to me,
>    first because the references do not match anything in the template
>    and second because they are not even rooted in the template or
>    Terms elements, so the structure is underconstrained if it is meant
>    to imply the presence of such terms.  Shouldn't we require a
>    wrapping element around XPath expressions to indicate how they are
>    interpreted against template or offer documents?

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.

> 
> 2) What is the matching rule for template content to determine if an
>    offer or agreement is consistent with a template?
> 
>    Must all of the CreationConstraints/Item elements be able to
>    reference a structure in the offer?  Must a structure satisfy all
>    content restrictions which reference it?
> 
>    Isn't the spec odd in stating that offers MUST match and providers
>    MUST reject non-matching offers when the matching semantics are not
>    really well-defined?  Shouldn't this all be treated as hints
>    anyway, with freedom for both parties to offer and/or accept
>    non-matching agreements if they like?

Agreed. In a no tso loosely couple scenario, one might not want to publish 
templates because, e.g., just one integer value is variable and the client 
creates agreement offers just by string concatenation. I propose to delete 
the requirement on template compliance, probably the whole section.

> 3) Shouldn't CreationConstraints/Constraint have open content?
> 
>    It seems like this is a hold-over from when we were trying to
>    handle extensibility through schema extension.  The specification
>    text says it is am empty element which must be extended. Shouldn't
>    it be a non-derivable type w/ xsd:any##other child?

ok
 
> 4) What are the rule for using templates?
> 
>    MUST an offer be based on a template?  MUST a provider publish
>    templates at all?  SHOULD the provider use the optional
>    Template/Name field?

As discussed above, no, from a spec point of view. In reality, one would 
probably mostly use it to come up with agreement offers that both parties 
can understand.

 
> 5) Should the base specification include template syntax to describe
>    compositions of terms?
> 
>    It seems like there should be a way to express compositions of
>    terms without having to enumerate specific composition instances as
>    separate templates.  Unless I have misunderstood the generality of
>    the existing syntax, do we need a new form of template or some
>    other extensibility hook to allow more general templates?
> 
>    Should the overall template handling rules be liberalized to either
>    have a wildcard template or an understanding that domain-specific
>    template mechanisms may be in place which capture complex or
>    precise templating scenarios which cannot be adequately projected
>    into the basic template syntax?

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.
 
> 6) Should we drop templates from the first version?
> 
>    If the above questions cannot be answered and addressed shortly, is
>    it better to produce a standard w/o templates or to delay until we
>    can solve these problems?  What is the use case requirement for
>    determining of the spec mechanism is good enough to publish?  I am
>    not confident that we really know how to, for example, express
>    constraints against a single complex JSDL service description term
>    with its optional parts.
 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050428/3fe58f13/attachment.html