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