On Jul 21, Heiko Ludwig modulated: ...
First, i want to raise my only real conceptual concern with the OPP: There is a dependency between items which is a little bit hidden in the XPATHs, which we don't require as location instrument. An item 1 at /a/ b/c can only be inserted if /a/b exist. If /a/b is optional, determined by choosing to fill in another item 2, item 1 depends on item 2. This dependency is only understandable by analysing the XPATH expression, which is no tpart of the standard. This is a serioud concern. It could be dealt with by explicitly listing dependencies, but this is additional hastle.
Yes, there is clearly a lot of modeling decisions for the template creator which can make the template more or less readable and informative for understanding the acceptable offer space. However, I think that is really true with the TPP approach too, e.g. deciding what to put in the prototype and what to put in the constraint schema. In either case, I think there is a possibly tricky inference step to determine from a template what kind of offer to produce, though I think both cases are relatively straightforward to validate offers after the fact. (More below.) I suspect that in practice, other abastract, domain-specific resource properties will help guide this process so that the template is understood within a context and need only be consulted for its "restrictions" rather than for ultimate guidance on "what are the agreements all about?"
My other concerns mostly relate to the pragmatics and my lack of understanding of how to implement this well:
- The pointers in the OFP may point to not yet existing locations in the editing process of the templates. XPATHs, if this is the chosen location mechanism (and I guess it will), are not nice to write by hand reliably, really. Ideally, you want to have an editor where you can point to an element and the XPath is returned. Xerces, for example supports this. With OPP pointers the author is probably on its own, as far as I understand the current tooling environment.
However, we know that the TPP format really only works for flat/simple domain languages (because once it gets non-flat and non-simple, you end up having to cram all the information into the constraint(s) rather than the prototype). I would argue that in the flat/simple language use case, it is not actually that difficult to generate the XPath expressions by hand. So, you don't really get any major benefit from editor-generated XPath expressions in either case! :-) So yes, definitely XPath can be tricky but I hope you see value in allowing its use for those cases where it can be expressive in moderation. Unless I am confused, I think the OPP approach still allows the more "conservative" granularity of the TPP where only a few relatively deterministic Locations are used and the constraints are more complete document elements, e.g. one constraint can act as the "prototype" though it is in schema format instead of doc format. Additionally, I guess we could add a special "prototype" constraint, akin to the "literal" part of the proposal, as long as we can come up with the right validation rules? (Do we need to have a prototype that gives positive restrictions, like "this element, if it appears, has to have this value", from negative restrictions like, "only these elements are allowed".) The downside would be that this is basically adding more WS-Agreement specific content modeling, for what is arguably syntactic sugar of equivalently expressive XSD.
- For the same reason, the pointers to potential future offer locations, the consistency check of authored templates is more difficult, or at least appears to me so as of now.
- The verification of an offer with its constraints appears to become harder. In the TPP approach, all item constraint follow the exact interpretation semantics of the schema, no assumptions. One can verify an items value by taking the XML to which an XPath points, take the XML schema constraint associated with item and match it, e.g., using standard Xerces funtionality. In the OPP case, when verifying an item, one has to look through all items to analyze which contraints or type definitions apply and then merge them with the local constraint to execute the full verification using an XML parser - and hope that they are more consistent.
I think the verification of an offer is straightforward as a multi-step process for OPP: 1. validate offer using WS-Agreement normative schema and the domain-specific schema (assuming the infrastructure can do type validation of open-content elements) 2. for each Item, do: find xpath selection using Item/Location against offer doc if selection nodeset is non-empty OR Item/Location/@required=true then validate nodeset using Item/child[2] content model endif The validation stops on the first validation sub-step that fails. Of course, the validate routine in step (2) has to handle our special forms e.g. wsag:literal or wsag:prototype if we support them, while calling the XSD-aware libraries to handle the XSD schematic fragments. I assume the process would have to be similar to validate the TPP constraints? Or, do you see a way to merge the constraints into a new schema that is used to validate in one pass? It seems you either need to generate a schema transliteration of the prototype as a restriction of the base type, or do some other structural unification of offer and prototype to make sure there is nothing "deviating" (either extra or missing) in the offer that is not allowed by a constraint. In either case, it seems a robust implementation should do the step (1) of validating using the unconstrained WS-Agreement and domain-specific schemas to make sure we are only processing restrictions and not some other strange dialect...
Hence, for evaluating our alternatives, we must take into account the dependency issue as well as the pragmatic concerns that I was raising. An additional decision -criterion is where we see the most probable uses cases: relatively simple fill-in items or items with a lot of compostitional complexity that must be guided.
Heiko
Do you see the value of the prototype as a convenience for authoring templates for for consuming them? I am wondering if it would help to discuss a "template authoring strategy" where a prototype can be automagically converted into OPP form? (not that I already have one handy) I also have to admit one hesitation I have to all of this if you want to talk pragmatics: I don't really know how this simple concept of "restricting" an open standard schema like WS-Agreement and/or domain languages works in practice with tools. It means we are basically defining alternative type and element definitions for things in standard namespaces! Superficially, this sort of thing seems like it would be frowned upon, since the standard QNames are supposed to be "write once" and by a different authority to boot! I think this is an area where experimentation will have to be done, because clearly these sorts of restricting profiles are critical to the notion of Grid interop... karl -- Karl Czajkowski karlcz@univa.com