[graap-wg] Templates too restrictive?

[Karl Czajkowski]

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?

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?

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?

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?

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?

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.


karl

-- 
Karl Czajkowski
karlcz at univa.com