From jim_pruyne at hp.com Wed Jul 6 00:30:50 2005 From: jim_pruyne at hp.com (Jim Pruyne) Date: Wed, 06 Jul 2005 00:30:50 -0500 Subject: [graap-wg] no telecon on 7/6 Message-ID: <42CB6C8A.9030908@hp.com> Folks, I'm assuming that most of you are like me, and are still catching up after the week at GGF and the 4th holiday here in the US. So, I'm cancelling our call on the 6th, and we'll resume at the usual time on the 13th. --- Jim From jim_pruyne at hp.com Wed Jul 13 01:31:36 2005 From: jim_pruyne at hp.com (Jim Pruyne) Date: Wed, 13 Jul 2005 01:31:36 -0500 Subject: [graap-wg] teleconference on 7/13 Message-ID: <42D4B548.6090408@hp.com> All, We'll resume our teleconference schedule this week. The times and numbers will be the same as usual: Start Time: 10:00 AM Central US 11:00 AM Eastern US 8:00 AM Pacific US 1700 Germany 1600 UK Midnight Japan Dial in numbers: 866-673-8466 or 702-477-6031 code 8578310. My hope is to re-visit some of the issues raised during our "status" session at GGF, and define a plan for completing the spec. I'd also be interested to hear what people's opinions of GGF14 were. Thanks. --- Jim From t-nakata at cw.jp.nec.com Wed Jul 13 04:18:42 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Wed, 13 Jul 2005 18:18:42 +0900 Subject: [graap-wg] Two more minor comments in the spec. In-Reply-To: <42D4B548.6090408@hp.com> References: <42D4B548.6090408@hp.com> Message-ID: <42D4DC72.7010404@cw.jp.nec.com> Hi: Just in case I don't make it to the telecon (I intend to, ) Here are two more minor comments in the spec. 1)Figure 1 has a resource property named relatedAgreements. in it 2)Chapter 7 Runtime states has 7.1 Agreement States 7.2 Service Runtime States 7.3 Gurantee States Which is fine.. on the other hand Section 9.5 Port type wsag:Agreement State only has 9.5.1 Resource Property wsag:ServiceTermStateList and 9.5.2 Resource Property wsag:GuaranteeTermStateList only. Perhaps another resource property named wsag:AgreementState is necessary? And if it is confusing to have AgreementState in both Port type and Resource Property, Perhaps the Port type should be renamed to something like Port type wsag:AgreementRuntimeState? Also, 9.5's description This port type is not meant to be used as is but instead, its resource properties MAY be composed into a domain-specific Agreement port type. seems confusing for me. Best regards Toshi -- Toshiyuki Nakata ????? Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7609 (NEC Internal 22-60509) From jim_pruyne at hp.com Wed Jul 13 14:30:31 2005 From: jim_pruyne at hp.com (Jim Pruyne) Date: Wed, 13 Jul 2005 14:30:31 -0500 Subject: [graap-wg] Two more minor comments in the spec. In-Reply-To: <42D4DC72.7010404@cw.jp.nec.com> References: <42D4B548.6090408@hp.com> <42D4DC72.7010404@cw.jp.nec.com> Message-ID: <42D56BD7.2040900@hp.com> I think Toshi's found something missing here. I cannot see the resource property representing the global agreement state, but perhaps I'm missing it. However, in looking around, I see that the schema in the appendix defines agreement states as: wsag:beforeObserved, wsag:observed, and wsag:afterObserved. The text seems to say the states are: pending, observerd, rejected, complete. Am I missing something, or is this just not consistent at this point. Are we agreed with the states defined in 7.1 to the point that the schema should be changed? I've made the change for issue 1 here, and will upload the changed version now. --- Jim Toshiyuki Nakata wrote: > > Hi: Just in case I don't make it to the telecon (I intend to, ) > Here are two more minor comments in the spec. > 1)Figure 1 has a resource property named relatedAgreements. in it > 2)Chapter 7 Runtime states has > 7.1 Agreement States > 7.2 Service Runtime States > 7.3 Gurantee States > Which is fine.. > on the other hand Section 9.5 Port type wsag:Agreement State > only has > 9.5.1 Resource Property wsag:ServiceTermStateList > and > 9.5.2 Resource Property wsag:GuaranteeTermStateList > > only. > Perhaps another resource property named wsag:AgreementState > is necessary? > > And if it is confusing to have AgreementState in both Port type and > Resource Property, > Perhaps the Port type should be renamed to something like > Port type wsag:AgreementRuntimeState? > > Also, > 9.5's description > This port type is not meant to be used as is but instead, its resource > properties > MAY be composed into a domain-specific Agreement port type. > > seems confusing for me. > > Best regards > Toshi > From hludwig at us.ibm.com Wed Jul 13 14:59:11 2005 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Wed, 13 Jul 2005 15:59:11 -0400 Subject: [graap-wg] Complex Constraints, our call today In-Reply-To: <42D56BD7.2040900@hp.com> Message-ID: As discussed in our call today, I looked into the XML Schema schema (no typo) to figure out whether we can reuse a good schema constraint to represent template constraints not only pertaining to simple types. >From my point of view, we have two choices: 'complexType' uses this typeDefParticle asks for all, choice and sequence, plus group as the top-level element. nestedParticle allows us to define a element straight away - and its type. The types localElement or topLevelElement would just allow to define an element, which could be good enough. In case we want high flexibilty, let's take nestedParticle, otherwise topLevelElement. It would be alternative to the simpleRestrictions we already have. Opinions? Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050713/9e4c0ab8/attachment.html From hludwig at us.ibm.com Thu Jul 14 09:24:41 2005 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Thu, 14 Jul 2005 10:24:41 -0400 Subject: [graap-wg] Two more minor comments in the spec. In-Reply-To: <42D56BD7.2040900@hp.com> Message-ID: Jim, wsag:beforeObserved, wsag:observed, and wsag:afterObserved was the state model before the asynchronous additions in the last revision. Karl proposed this new state model to accommodate the state of an agreement that has not been decided upon yet by the agreement provider. Is this right, Karl? Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/ Jim Pruyne Sent by: owner-graap-wg at ggf.org 07/13/2005 03:30 PM To t-nakata at cw.jp.nec.com cc GRAAP-WG Subject Re: [graap-wg] Two more minor comments in the spec. I think Toshi's found something missing here. I cannot see the resource property representing the global agreement state, but perhaps I'm missing it. However, in looking around, I see that the schema in the appendix defines agreement states as: wsag:beforeObserved, wsag:observed, and wsag:afterObserved. The text seems to say the states are: pending, observerd, rejected, complete. Am I missing something, or is this just not consistent at this point. Are we agreed with the states defined in 7.1 to the point that the schema should be changed? I've made the change for issue 1 here, and will upload the changed version now. --- Jim Toshiyuki Nakata wrote: > > Hi: Just in case I don't make it to the telecon (I intend to, ) > Here are two more minor comments in the spec. > 1)Figure 1 has a resource property named relatedAgreements. in it > 2)Chapter 7 Runtime states has > 7.1 Agreement States > 7.2 Service Runtime States > 7.3 Gurantee States > Which is fine.. > on the other hand Section 9.5 Port type wsag:Agreement State > only has > 9.5.1 Resource Property wsag:ServiceTermStateList > and > 9.5.2 Resource Property wsag:GuaranteeTermStateList > > only. > Perhaps another resource property named wsag:AgreementState > is necessary? > > And if it is confusing to have AgreementState in both Port type and > Resource Property, > Perhaps the Port type should be renamed to something like > Port type wsag:AgreementRuntimeState? > > Also, > 9.5's description > This port type is not meant to be used as is but instead, its resource > properties > MAY be composed into a domain-specific Agreement port type. > > seems confusing for me. > > Best regards > Toshi > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050714/a3ca6d7b/attachment.html From t-nakata at cw.jp.nec.com Mon Jul 18 23:14:39 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Tue, 19 Jul 2005 13:14:39 +0900 Subject: [graap-wg] TobeResolvedList In-Reply-To: <42D4B548.6090408@hp.com> References: <42D4B548.6090408@hp.com> Message-ID: <42DC7E2F.4080504@cw.jp.nec.com> Hi: I've tried to resurrect the Public Comments List and the tobe Resolved List. If I'm missing some entries (I'm sure I've missed some things out9 please let me know. Best regards Toshi > -- Toshiyuki Nakata ????? Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7609 (NEC Internal 22-60509) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050719/35f9f25b/attachment.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050719/35f9f25b/attachment-0001.htm From hludwig at us.ibm.com Tue Jul 19 15:08:54 2005 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Tue, 19 Jul 2005 16:08:54 -0400 Subject: [graap-wg] FYI, WS-Agreement Ontology at U of Georgia Message-ID: Dear GRAAP members, FYI, I just learned about this WS-Agreement ontology: http://lsdis.cs.uga.edu/projects/meteor-s/modulePages/index.php?page=2 It's interesting to browse. It is part of the Meteor-S project going on at the LSDIS Lab at U. of Georgia, under Amit Sheth: http://lsdis.cs.uga.edu/projects/meteor-s/ Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050719/1bf211e2/attachment.html From hludwig at us.ibm.com Wed Jul 20 08:45:21 2005 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Wed, 20 Jul 2005 09:45:21 -0400 Subject: [graap-wg] Re: Fw: Complex Constraints, our call today In-Reply-To: Message-ID: Dear GRAAP members, one of the last open issues for the next release of our spec was the semantics of compositors and the use of templates. There were some concerns about using compositors on a template as well as offer/agreement level, potentially introducing semantic ambiguity as to who must or can exercise options. After some discussion since the last call, Toshi, karl and I propose the following, to be discussed in today's call: 1. Compositors have agreement offer-level semantics only. They are not to be interpreted as choices of the initiator. 2. To express more flexibility, we propose to extend the CreationConstraints as follows: Add an attribute "mode" to Location that can be "insert" or "replace". If the value is set to replace, have another attribute "before" with values of positive integers and "end". With those instruments in addition to complex types in creation contraints we can express, for example, the following: ... myfixedvalue default value ... //ns1:fieldB //ns1:docroot // You could inline a more complex element here. // To any fieldB element, we can add more arbitrary input, e.g., file names etc. Using the added expressivness of the Location element, we can deal with zero or more cardinalities. I propose to use schema for associating the occurrance of one element (fieldC) with another (fieldC). You cannot express this in either the Infoset notation nor the compositors. This way, we achieve a pretty powerful composition semantics, do not replicate expressivness covered by schema and don't need template-level compositors. Talk to you at 11 EST, Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050720/f34d84a1/attachment.html From hludwig at us.ibm.com Wed Jul 20 10:05:26 2005 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Wed, 20 Jul 2005 11:05:26 -0400 Subject: [graap-wg] Call today? Message-ID: The call is not activated. Is there a call right now? Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050720/830af54a/attachment.html From hludwig at us.ibm.com Wed Jul 20 10:18:16 2005 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Wed, 20 Jul 2005 11:18:16 -0400 Subject: [graap-wg] Fw: Call today? Message-ID: Let's use this number for today, as Jim cannot make it. Toll-free dial-in: 1-877-421-0025 Toll dial-in: 1-770-615-1242 Participant passcode: 598600 Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/ ----- Forwarded by Heiko Ludwig/Watson/IBM on 07/20/2005 11:17 AM ----- Heiko Ludwig/Watson/IBM wrote on 07/20/2005 11:05:25 AM: > The call is not activated. Is there a call right now? > > Heiko > > ----- > Heiko Ludwig, Dr. rer. pol. > IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 > hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 > http://www.research.ibm.com/people/h/hludwig/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050720/a9f9b7ab/attachment.html From Wolfgang.Ziegler at scai.fraunhofer.de Wed Jul 20 10:20:13 2005 From: Wolfgang.Ziegler at scai.fraunhofer.de (Wolfgang Ziegler) Date: Wed, 20 Jul 2005 17:20:13 +0200 Subject: [graap-wg] Call today? In-Reply-To: References: Message-ID: <42DE6BAD.7070607@scai.fraunhofer.de> well, nothing but music for the last 15 minutes. - I decided to hang up and wait for mail from Jim. Probably I missed that there was no telecon today. Wolfgang Heiko Ludwig wrote: > > The call is not activated. Is there a call right now? > > Heiko > > ----- > Heiko Ludwig, Dr. rer. pol. > IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 > hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 > http://www.research.ibm.com/people/h/hludwig/ > -- Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2258 Fax: +49 2241 14 42258 http://www.scai.fraunhofer.de "Heut ist nicht so kalt wie gestern, trotzdem dass heut kaelter ist" -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3761 bytes Desc: S/MIME Cryptographic Signature Url : http://www.ogf.org/pipermail/graap-wg/attachments/20050720/c763d112/attachment.bin From jim_pruyne at hp.com Wed Jul 20 11:08:00 2005 From: jim_pruyne at hp.com (Jim Pruyne) Date: Wed, 20 Jul 2005 11:08:00 -0500 Subject: [graap-wg] Call today? In-Reply-To: <42DE6BAD.7070607@scai.fraunhofer.de> References: <42DE6BAD.7070607@scai.fraunhofer.de> Message-ID: <42DE76E0.1000706@hp.com> Folks, Sorry for the mess-up. There was a rather significant work-related event that got scheduled for the same time as the call, and I simply failed to let everyone know. Would Fri. at the same time work for people? Heiko, thanks for your efforts to arrange an alternative number. --- Jim Wolfgang Ziegler wrote: > well, nothing but music for the last 15 minutes. - I decided > to hang up and wait for mail from Jim. Probably I missed that > there was no telecon today. > > Wolfgang > > Heiko Ludwig wrote: > >> >> The call is not activated. Is there a call right now? >> >> Heiko >> >> ----- >> Heiko Ludwig, Dr. rer. pol. >> IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 >> hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 >> http://www.research.ibm.com/people/h/hludwig/ >> > From karlcz at univa.com Wed Jul 20 13:13:50 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Thu, 21 Jul 2005 01:13:50 +0700 Subject: [graap-wg] Alternative Approach to Templates and Constraints In-Reply-To: References: Message-ID: <20050720181350.GC5413@moraine.casacz> Heiko and GRAAP: I think I have narrowed down my discomfort with the current template proposal... basically, I think we are on the right track with the creation constraints but the prototype aspect is still too biased towards a particular flavor of domain-specific term language that is "flat" and has no variable-cardinality content. Once you start wanting to admit a domain language with optional fields or repeatable fields WITHOUT TOTALLY CONSTRAINING ITS USE, this approach gets in the way. EVALUATION CRITERIA We of course need to keep focused on delivering a specification, so I am writing this email with the intent that people can review my suggestions and decide if they make sense and are easy enough to write into the specification without any non-trivial change to the schedule, i.e. Heiko should feel that it isn't more complex or open-ended than his proposal in terms of specification content, and that it also seems beneficial, and others should agree as well. :-) My concept of an "ideal" template is one that does the following in a very concise manner (in rough order of importance): 1. identify the domain-specific language(s) that are allowed in terms 2. specify the prototype values for terms, e.g. fixed or default** values which are specific to one WS-Agreement service rather than schema-level fixed/default values 3. specify other more general content restrictions, e.g. identify a place where the domain-language has open content and specify a smaller list of recognized extensions that are acceptable 4. related to (1), specify the compositional rules/restrictions for terms in an offer, e.g. the whole "template composition" discussion. this is basically a matter of asserting restrictions to the generic wsag:compositor syntax of the offer. 5. assumes schema-level understanding of the content model in the absence of prototypes and restrictions, i.e. do not require the template to re-state the structural requirements of the domain language if the WS-Agreement service is not trying to restrict it further In other words, the offer MUST (SHOULD?) conform to the WS-Agreement envelope and domain-specific term schemas, and it also MUST (SHOULD?) conform to the additional prototypes and restrictions of the template! The current proposal doesn't allow concise mixing of the prototype and restriction mechanisms. You end up having to either generate a large set of creation constraints that express the different parts of the domain schema (redundantly) against a prototype, or you cannot use the prototype feature and you provide one more compact creation constraint. My view is that the current prototype mechanism is not valuable enough to keep, when a slight modification to the constraint model can cover the case where it is concise (a simple fixed list of values). ALTERNATE PROPOSAL Make the entire template a set of constraint rules which have a new "triggering" and "reference" model: they refer to the eventual offer document by XPath instead of the (now non-existent) prototype document. Furthermore, they are softened by default to only apply IF their XPath reference matches content in the prototype. (If they select an empty "nodeset" from the offer, they are ignored by default.) An extra attribute is permitted to override this soft triggering model and REQUIRE that the nodeset references by the Xpath (even if empty) match the constraint's content model. XPath ...XSD content model... Whatever content in the offer is addressed by /Item/Location must conform to the content model in the rule. The Location is evaluated with the wsag:offer element as the root. This content model can be any of the following to cover our use cases: 1. a literal value or subtree to cover the fixed/prototype case 2. a simple restriction for the old enumeration use case 3. a complex restriction/group for the new structural restriction 4. an attribute group to cover the bases for reasonable XPath references? There is an implicit rule in every template which could be made explicit without harm: /wsag:AgreementOffer Which by itself means that the offer must conform to the WS-Agreement normative schema. A minimal open-ended template might just want to identify the domain language and a simple compositor structure without making additional restrictions: /wsag:AgreementOffer/wsag:Terms/wsag:All/* //wsag:ServiceDescriptionTerm/* The first rule says that the offer must have the very simple form of an All compositor with one child element ServiceDescriptionTerm... the number of children could be opened up with cardinality attributes in the sequence definition of the rule. Alternatively, someone could write a rule with Location /wsag:AgreementOffer and then provide more inline typing to give a restriction of it? The second rule says that the (any) service description term must have the tns:docroot domain-specific element in it. A benefit of this approach for complex domain languages is that the variable structure of the domain language is preserved with all its flexibility UNLESS the template lists constraints against the structure. Someone more familiar with XPath and/or XSD may be able to show a more compact way to write both of these conditions into one rule. To do the fixed value fieldA from Heiko's email: //tns:docroot/fieldA/text() fixed value i.e. we define one "literal" content model to handle the prototype cases concisely. (Is there an XSD feature that works as well? The most concise I can think of is a one-element enumeration restriction...) These rules can be overlapping at different depths in the tree, so that the "top-level" rules fix the superstructure with brief ref=elementname descriptions of structure, implying that the general purpose elementname schema is acceptable, while later rules further restrict the use of that schema by referencing substructures in the descendents of elementname. Thus, I hope I have demonstrated that this approach is just as expressive in terms of conveying information about offer requirements to the human. I do not think we have use-cases in mind yet where we can evaluate the automatic consumption of templates by schema-aware software. :-( I think this is more general and consistent w/ the nodeset/infoset model of XPath selection, e.g. rules select parts of the offer and define schematic requirements on those selected parts. EXAMPLE Here is the concrete example w/ the same implied offer content as Heiko's email example, e.g. I've left out the same contextual bits as were left out in his! Note that the only reason I have to assert a constraint for fieldC is because I am restricting its cardinality. Otherwise, I could leave it off and the consumer of the template would assume the schema definition for tns:docroot is the only constraint, e.g. fieldC would be unbounded or whatever cardinality is given in the schema. karl ** I want to raise the idea that a default value semantics (B) that differs from the domain-specific schema is a confusing topic. Shouldn't a term document have the same meaning everywhere? (Shouldn't the domain schema remain normative for interpreting the absence of content?) If we want to advertise a "default", maybe it should really be a weaker form of constraint which has the meaning "we recommend this value if you don't have any other preference", but it is still the initiators responsibility to fill in some value? -- Karl Czajkowski karlcz at univa.com From hludwig at us.ibm.com Wed Jul 20 23:57:43 2005 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Thu, 21 Jul 2005 00:57:43 -0400 Subject: [graap-wg] Re: Alternative Approach to Templates and Constraints In-Reply-To: <20050720181350.GC5413@moraine.casacz> Message-ID: Karl, thank you for your specific proposal. This enables some concrete discussion. Overall, I see a trade-off between your proposal (let's call it offer pointer proposal (OPP) ) and the one we came up yesterday (template pointer proposal (TPP) ) are quite similar in expressiveness.The OPP requires a little less specification lines while the TPP is a little easier to implement in a verifier and provide a good aditor. Also, The TPP seems to be a bit more convenient for a mostly static template with fields of moderate complexity while the OFP appears to be easier when a template is very open, with relatively "big" fields in a rudimentary main agreement prototype but insertable content using prototype content in and for the fill-in items. I will detail this in a second. 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. 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. - 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. 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 ---- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/ Karl Czajkowski wrote on 07/20/2005 02:13:50 PM: > > Heiko and GRAAP: > > I think I have narrowed down my discomfort with the current template > proposal... basically, I think we are on the right track with the > creation constraints but the prototype aspect is still too biased > towards a particular flavor of domain-specific term language that is > "flat" and has no variable-cardinality content. Once you start > wanting to admit a domain language with optional fields or repeatable > fields WITHOUT TOTALLY CONSTRAINING ITS USE, this approach gets in the > way. > > > EVALUATION CRITERIA > > We of course need to keep focused on delivering a specification, so I > am writing this email with the intent that people can review my > suggestions and decide if they make sense and are easy enough to write > into the specification without any non-trivial change to the schedule, > i.e. Heiko should feel that it isn't more complex or open-ended than > his proposal in terms of specification content, and that it also seems > beneficial, and others should agree as well. :-) > > My concept of an "ideal" template is one that does the following in > a very concise manner (in rough order of importance): > > 1. identify the domain-specific language(s) that are allowed > in terms > > 2. specify the prototype values for terms, e.g. fixed or default** > values which are specific to one WS-Agreement service rather > than schema-level fixed/default values > > 3. specify other more general content restrictions, e.g. identify > a place where the domain-language has open content and specify > a smaller list of recognized extensions that are acceptable > > 4. related to (1), specify the compositional rules/restrictions > for terms in an offer, e.g. the whole "template composition" > discussion. this is basically a matter of asserting restrictions > to the generic wsag:compositor syntax of the offer. > > 5. assumes schema-level understanding of the content model in > the absence of prototypes and restrictions, i.e. do not require > the template to re-state the structural requirements of the > domain language if the WS-Agreement service is not trying to > restrict it further > > In other words, the offer MUST (SHOULD?) conform to the WS-Agreement > envelope and domain-specific term schemas, and it also MUST (SHOULD?) > conform to the additional prototypes and restrictions of the template! > > The current proposal doesn't allow concise mixing of the prototype and > restriction mechanisms. You end up having to either generate a large > set of creation constraints that express the different parts of the > domain schema (redundantly) against a prototype, or you cannot use the > prototype feature and you provide one more compact creation > constraint. > > My view is that the current prototype mechanism is not valuable enough > to keep, when a slight modification to the constraint model can cover > the case where it is concise (a simple fixed list of values). > > > ALTERNATE PROPOSAL > > Make the entire template a set of constraint rules which have a new > "triggering" and "reference" model: they refer to the eventual offer > document by XPath instead of the (now non-existent) prototype > document. Furthermore, they are softened by default to only apply IF > their XPath reference matches content in the prototype. (If they > select an empty "nodeset" from the offer, they are ignored by > default.) An extra attribute is permitted to override this soft > triggering model and REQUIRE that the nodeset references by the Xpath > (even if empty) match the constraint's content model. > > > XPath > ...XSD content model... > > > Whatever content in the offer is addressed by /Item/Location must > conform to the content model in the rule. The Location is evaluated > with the wsag:offer element as the root. This content model can be any > of the following to cover our use cases: > > 1. a literal value or subtree to cover the fixed/prototype case > > 2. a simple restriction for the old enumeration use case > > 3. a complex restriction/group for the new structural restriction > > 4. an attribute group to cover the bases for reasonable XPath > references? > > There is an implicit rule in every template which could be made > explicit without harm: > > > /wsag:AgreementOffer > > > > > > Which by itself means that the offer must conform to the WS-Agreement > normative schema. > > A minimal open-ended template might just want to identify the domain > language and a simple compositor structure without making additional > restrictions: > > > > /wsag:AgreementOffer/wsag:Terms/wsag:All/* > > > > > > > //wsag:ServiceDescriptionTerm/* > > > > > > The first rule says that the offer must have the very simple form of > an All compositor with one child element ServiceDescriptionTerm... the > number of children could be opened up with cardinality attributes in > the sequence definition of the rule. Alternatively, someone could > write a rule with Location /wsag:AgreementOffer and then provide more > inline typing to give a restriction of it? > > The second rule says that the (any) service description term must have > the tns:docroot domain-specific element in it. A benefit of this > approach for complex domain languages is that the variable structure > of the domain language is preserved with all its flexibility UNLESS > the template lists constraints against the structure. > > Someone more familiar with XPath and/or XSD may be able to show a more > compact way to write both of these conditions into one rule. > > To do the fixed value fieldA from Heiko's email: > > > //tns:docroot/fieldA/text() > fixed value > > > i.e. we define one "literal" content model to handle the prototype > cases concisely. (Is there an XSD feature that works as well? The > most concise I can think of is a one-element enumeration > restriction...) > > These rules can be overlapping at different depths in the tree, so > that the "top-level" rules fix the superstructure with brief > ref=elementname descriptions of structure, implying that the general > purpose elementname schema is acceptable, while later rules further > restrict the use of that schema by referencing substructures in the > descendents of elementname. > > Thus, I hope I have demonstrated that this approach is just as > expressive in terms of conveying information about offer requirements > to the human. I do not think we have use-cases in mind yet where we > can evaluate the automatic consumption of templates by schema-aware > software. :-( I think this is more general and consistent w/ the > nodeset/infoset model of XPath selection, e.g. rules select parts of > the offer and define schematic requirements on those selected parts. > > > EXAMPLE > > Here is the concrete example w/ the same implied offer content as > Heiko's email example, e.g. I've left out the same contextual bits as > were left out in his! > > > > Note that the only reason I have to assert a constraint for fieldC is > because I am restricting its cardinality. Otherwise, I could leave it > off and the consumer of the template would assume the schema > definition for tns:docroot is the only constraint, e.g. fieldC would > be unbounded or whatever cardinality is given in the schema. > > > karl > > > ** I want to raise the idea that a default value semantics (B) that > differs from the domain-specific schema is a confusing topic. > Shouldn't a term document have the same meaning everywhere? (Shouldn't > the domain schema remain normative for interpreting the absence of > content?) If we want to advertise a "default", maybe it should really > be a weaker form of constraint which has the meaning "we recommend > this value if you don't have any other preference", but it is still > the initiators responsibility to fill in some value? > > > > -- > Karl Czajkowski > karlcz at univa.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050721/0cd5a0b1/attachment.html From karlcz at univa.com Thu Jul 21 01:24:14 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Thu, 21 Jul 2005 13:24:14 +0700 Subject: [graap-wg] Re: Alternative Approach to Templates and Constraints In-Reply-To: References: <20050720181350.GC5413@moraine.casacz> Message-ID: <20050721062414.GA20203@moraine.casacz> 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 From t-nakata at cw.jp.nec.com Thu Jul 21 04:17:34 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Thu, 21 Jul 2005 18:17:34 +0900 Subject: [graap-wg] Fw: Call today? In-Reply-To: References: Message-ID: <42DF682E.5010804@cw.jp.nec.com> Hi: I took the liberty of borrowing lots of Heiko's 9.5.1 section to try to sketch out the new section on 9.5.1 which deals with the AgreementStateList.. (With the aim of trying to complete the draft ASAP) Rather than clatter the MLwith the whole doc., or having the sections renumbered, I am sending the pdf of the relevant part of the draft. (Sorry, some of the output is from Japanese WORD..) Any comments are appreciated. PS ( No I have not touched the WSDL part yet..) Best Regards Toshi -- Toshiyuki Nakata ????? Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) -------------- next part -------------- A non-text attachment was scrubbed... Name: WS-AgreementSpecificationDraf050718.pdf Type: application/pdf Size: 55258 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20050721/e756d223/attachment.pdf From hludwig at us.ibm.com Fri Jul 22 09:41:40 2005 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Fri, 22 Jul 2005 10:41:40 -0400 Subject: [graap-wg] Fw: Alternative Approach to Templates and Constraints Message-ID: Dear GRAAP members, Karl and I had some email discussion since the Wednesday phone call to resolve the template issue. We agreed that both of our more complex proposals are not well enough throught through at the moment and it would be best to stick to a minimal solution, going only slightly beyond what we have in the 1 comments round draft: - A template contains an offer prototype and the creation contraints. - Creation constrains contain a set of items, each of which -- has a location as an XPath -- may have a simpleRestriction (as we had it) or a complex type restriction ( because it's easy) or any#other content to be interpreted as constraint in its domain. This gives us a good standard template functionality and enough space for experimental approaches to templates sitting on top of this standard and potentially being included in the next revision of WS-Agreement. Furthermore, the proposal is easy to implement. If you have comments on this speak up now. I will start changing the schema and text of the spec correspondingly next week. Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/ ----- Forwarded by Heiko Ludwig/Watson/IBM on 07/22/2005 10:29 AM ----- Karl Czajkowski 07/21/2005 11:28 PM To Heiko Ludwig/Watson/IBM at IBMUS cc Subject Re: Alternative Approach to Templates and Constraints OK. I also wonder if some experiments might be better off in a separate RP from template, but I think the extension idea below is reasonable for "fine tuning" of the model in some domains. Should the Location be fixed to XPath or handled via extensions, e.g. make the normative idiom something like /some/path/string ? (I made it wsagext so it could go in an any##other defined in the wsag namespace.) karl On Jul 21, Heiko Ludwig modulated: ... > - We keep the existing model of pointers in XPath. Current content is > default. > - Constraint in: > 1. simpleRestriction, the way we have now. that's our minimum. > 2. complexType, because it is the same than simpleRestrictions > and one can identify the root > any#other for experimenting. > > As for the standard, 1 and 2 only apply to existing locations. The > location can be interpreted differently otherwise. > > This way we can keep our proven model, don't have much extension and > implementations can be easily adapted. We also understand the limits. > With the additional any#other we are open for whatever comes to our > minds. > > I hope we can agree on this. > > Heiko -- Karl Czajkowski karlcz at univa.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050722/4ba488ea/attachment.html From jim_pruyne at hp.com Wed Jul 27 09:27:38 2005 From: jim_pruyne at hp.com (Jim Pruyne) Date: Wed, 27 Jul 2005 09:27:38 -0500 Subject: [graap-wg] Telecon. today Message-ID: <42E799DA.7060204@hp.com> There will be a telecon today. Usual time (in about half an hour) and numbers: Start Time: 10:00 AM Central US 11:00 AM Eastern US 8:00 AM Pacific US 1700 Germany 1600 UK Midnight Japan Dial in numbers: 866-673-8466 or 702-477-6031 code 8578310. Sorry for the late reminder/confirmation. --- Jim