[graap-wg] Re: Alternative Approach to Templates and Constraints

[Karl Czajkowski]

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 at univa.com