[graap-wg] Templates too restrictive?

[nakata]

Hello:I also have had many questions from
people considering implementing WS-Agreement on the
templates.

I had not realized that there were so many issues, but if it is as Karl 
says, I would
opt for 6) even if it means inter-operability issues might become a bit 
vague..

Toshi

Karl Czajkowski wrote:

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