Comments inline. Heiko owner-graap-wg@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.