- graap-wg - lists.ogf.org

Test message
by Asit Dan 25 May '05

25 May '05

Jim, you will know if this is working. Regards. Asit Dan, Ph.D. Manager, Autonomic Service Oriented Computing IBM T.J. Watson Research Center, 19 Skyline Drive, Hawthorne, NY 10532 Phone: (914) 784-6677; Fax. x6040; Internet: asit(a)us.ibm.com ----- Forwarded by Asit Dan/Watson/IBM on 05/25/2005 11:49 AM ----- Jim Pruyne <jim_pruyne(a)hp.com> 05/25/2005 11:33 AM To Asit Dan/Watson/IBM@IBMUS cc Subject graap-wg list test Asit, Can you send a test note to the graap-wg list to see if anyone's e-mail is going through? Thanks. --- Jim

1 0

minutes from 4/27 telecon
by Jim Pruyne 11 May '05

11 May '05

They are attached. --- Jim Minutes from Apr. 27 '05 Telecon Attendees --------- Jim Pruyne Philipp Wieder Asit Dan Karl Czajkowski Heiko Ludwig Agenda ------ - Item 26: This seems to be a hold over from negotiation. It should be removed. Note that xsd/wsdl is probably not kept consistent with the doc. in general at this point. - Item 28: Consistent/standard use of compositors. What is WS-Policy state at this point? **Action: we cannot reference WS-Policy as we do other specs. given its state. We could re-sync. with WS-Policy to get back to being more consistent with it, but it will not satisfy the comment that's looking for a stand-alone spec. that we can reference. Asit will look at this. - Item 25: Change things over to making the assesment interval contain a penalty and/or a reward. **Action: Heiko to make this change. - Item 33: Explain service reference better. **Action: Heiko will basically paste in the examples he's alredy done in the comment. - Item 30: Having these terms defined is really useful, but defining terms related to agreements on WS is outside the current scope. We'd love to see a companion spec., but it needs to stay outside the scope of the current spec.

3 3

Templates too restrictive?
by Karl Czajkowski 29 Apr '05

29 Apr '05

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 -- Karl Czajkowski karlcz(a)univa.com

3 3

4/27 telecon reminder
by Jim Pruyne 27 Apr '05

27 Apr '05

All, We will have a telecon. on Wed. morning/evening at our usual time. Dial-in numbers will be the same. The time is: 10:00AM Central Time US (GMT-0600) which should be: 11:00AM Eastern Time US 1600 UK 1700 Germany midnight Japan 2200 Thailand Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the US. Conference code #8578310. --- Jim

1 0

minutes from Apr. 20 telecon
by Jim Pruyne 22 Apr '05

22 Apr '05

They are attached. We plan to meet at the same time next week. Reminder to follow. --- Jim Minutes from Apr. '05 Telecon Attendees --------- Jim Pruyne Toshiyuki Nakata Heiko Ludwig Karl Czajkowski Agenda ------ - Heiko did updates to schema based on comments to 29. Multiplicity on the penalty and reward elements, and text to update. Introduced new 4.2.1 on term types to introduce extensibility for new term types. - Should we move obliged party up to the generic term definition? Does't seem to apply outside the SLA-like guarantee terms, so probably not. - Issue 34: Can we refine what a guarantee term points to? E.g. can we point to a particular method on a service rather than the service as a whole? Seems like a good idea. **Action: Add as suggested in the comment. Heiko to do this and add the text. - Issue 35: GuaranteeTerms may be specified relative to one another in terms of value/importance. This is pretty much already possible as specified, but there was consideration as to whether we could make it more specific about the expectation that some guarantees are more likely to fail. We're not sure right now how to specify that in a useful way, and the spec. already really covers the case, so we don't expect to make any changes on this right now. - Issue 36: THe concept is to be able to add a set of values for an objective based on various performance characteristics. The concept is a good one, but we can already capture this with various of guarantee terms. We'd rather wait until we have more experience rather than introduce this now since it is a conveince thing rather than a required thing. - Issue 27: Why is agreement name optional? Name's are not unique ids in any case, so we don't see how requiring the names helps. The agreement can be named by its EPR in any event if a unique id is needed. Some other contracts, e.g. mortgages, don't necessarily have a specific name on them. **Action: Add some text saying that the name is not a unique identifier, and that it is there for the purpose of "readability" of the agreement document. Heiko to add this comment. - How to review Karl's comments, and accept or reject so that are not change tracking marks all over. **Action: Jim to take editting pass to remove edit marks and commit them. Should clean up the doc. for editting purposes as we go forward. Will start with the next version from Heiko. - Jim should point out issues/topics in reminder rather than doing it on the fly. That lets people prepare better.

2 1

Fw: [graap-wg] minutes from telecon on 4/13/05
by Heiko Ludwig 20 Apr '05

20 Apr '05

----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig(a)us.ibm.com, tel. +1 914 784 7160, mob. +1 646 236 9453 http://www.research.ibm.com/people/h/hludwig/ ----- Forwarded by Heiko Ludwig/Watson/IBM on 04/20/2005 11:04 AM ----- Heiko Ludwig/Watson/IBM 04/20/2005 10:13 AM To Jim Pruyne <pruyne(a)hpl.hp.com> cc Asit Dan/Watson/IBM, John Rofrano/Thornwood/IBM Subject Re: [graap-wg] minutes from telecon on 4/13/05 Jim, I updated the draft as per our discussion last week. I didn't find a proper way to add a document to the GridForge that supercedes the current draft. Hence, I send it to you for you have the authorization as an admin. Since the call is near, we also might just want to send it to the mailing list. Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig(a)us.ibm.com, tel. +1 914 784 7160, mob. +1 646 236 9453 http://www.research.ibm.com/people/h/hludwig/ Jim Pruyne <pruyne(a)hpl.hp.com> Sent by: owner-graap-wg(a)ggf.org 04/13/2005 12:21 PM To GRAAP-WG <graap-wg(a)gridforum.org> cc Subject [graap-wg] minutes from telecon on 4/13/05 They are attached. We'll continue the current meeting times. --- Jim Minutes from Apr. 13 '05 Telecon Attendees --------- Jim Pruyne Heiko Ludwig Karl Czajkowski Wolfgang Zeigler Asit Dan Agenda ------ - What's up with the Author's list? Jim's not comfortable removing names without their consent, and he hasn't gotten consent from people when he's asked. - Summary of updates from Heiko's revision - Change to Penalty to contain an unbounded list of (Assesment Interval, value unit, value expr.) tuples. Proposed to just change so that we can have an unbounded number of Penalty clauses in the BusinessValueList **Action: Do this in the spec. Heiko will do this, and apply to Reward, etc. - Discussion of comment 29: Are the value terms really appropriate here, or does this need to be addressed someplace else? **Action: Response is that there is nothing else today, so this is an approach we suggest. This specification can considered optional in the sense that one need not include guarantee terms at all, but is useful in some domains we've looked at. In 4.2.5.1, we need to be clear on what parts are extensible to support this position. - Does this all lead to the need for extensible term types? E.g. an "option" as suggested by Heiko. It seems that there may be terms beyond the description (functional) and guarantee (non-functional) terms that we have now. Agreed that we should allow for extension of new term types. **Action: update section 4.2 to make the definition of new term types possible, and update the pseudo-schema in 4.2.1, and introduce a new-subsection before the compositor definition. *Comment: Use of xsd:anyother is a useful construct to specify that one can extend, but must use another namespace outside our own. *Comment: How do we make it clear in the pseudo-schema where extensibility is possible, and can we summarize somewhere all of the extensibility points. *Comment: Should we try to do some re-structuring to avoid the high-level of nesting that we have now (e.g. 5-levels of section numbering) **Action: Karl to do a re-write on 2.1 on motivating example on Job Submission, but it needs to stay up-to-date wrt later sections and examples in appendicies.

1 0

telecon reminder
by Jim Pruyne 20 Apr '05

20 Apr '05

All, As has become usual, we'll have our telecon tomorrow, Wed., 4/20 at the usual times and phone 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. --- Jim

1 0

minutes from telecon on 4/13/05
by Jim Pruyne 19 Apr '05

19 Apr '05

They are attached. We'll continue the current meeting times. --- Jim Minutes from Apr. 13 '05 Telecon Attendees --------- Jim Pruyne Heiko Ludwig Karl Czajkowski Wolfgang Zeigler Asit Dan Agenda ------ - What's up with the Author's list? Jim's not comfortable removing names without their consent, and he hasn't gotten consent from people when he's asked. - Summary of updates from Heiko's revision - Change to Penalty to contain an unbounded list of (Assesment Interval, value unit, value expr.) tuples. Proposed to just change so that we can have an unbounded number of Penalty clauses in the BusinessValueList **Action: Do this in the spec. Heiko will do this, and apply to Reward, etc. - Discussion of comment 29: Are the value terms really appropriate here, or does this need to be addressed someplace else? **Action: Response is that there is nothing else today, so this is an approach we suggest. This specification can considered optional in the sense that one need not include guarantee terms at all, but is useful in some domains we've looked at. In 4.2.5.1, we need to be clear on what parts are extensible to support this position. - Does this all lead to the need for extensible term types? E.g. an "option" as suggested by Heiko. It seems that there may be terms beyond the description (functional) and guarantee (non-functional) terms that we have now. Agreed that we should allow for extension of new term types. **Action: update section 4.2 to make the definition of new term types possible, and update the pseudo-schema in 4.2.1, and introduce a new-subsection before the compositor definition. *Comment: Use of xsd:anyother is a useful construct to specify that one can extend, but must use another namespace outside our own. *Comment: How do we make it clear in the pseudo-schema where extensibility is possible, and can we summarize somewhere all of the extensibility points. *Comment: Should we try to do some re-structuring to avoid the high-level of nesting that we have now (e.g. 5-levels of section numbering) **Action: Karl to do a re-write on 2.1 on motivating example on Job Submission, but it needs to stay up-to-date wrt later sections and examples in appendicies.

2 1

telecon reminder
by Jim Pruyne 13 Apr '05

13 Apr '05

All, We will have a telecon. on Wed. morning/evening at our new time. Dial-in numbers will be the same. The time is: 10:00AM Central Time US (GMT-0600) which should be: 11:00AM Eastern Time US 1600 UK 1700 Germany midnight Japan 2200 Thailand Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the US. Conference code #8578310. --- Jim

1 0

minutes from Apr. 6 telecon.
by Jim Pruyne 07 Apr '05

07 Apr '05

Are attached. We will continue to meet at the time used today which is, briefly, Wed. 10:00 AM Central time US. Reminders to follow. --- Jim Minutes from Apr. 06 '05 Telecon Attendees --------- Toshiyuki Nakata Jim Pruyne Heiko Ludwig Karl Czajkowski Wolfgang Zeigler Agenda ------ - New Call Time of Wed. at 10:00 Central US seems good at least for those on the phone, and objectively looking at various times - Updated doc. in gridforge from Karl, should be base-line for updates. We'll discuss comments on future call and accept or reject on-line. Heiko will make changes before the end of the week. - Question on updated doc. from Karl: Question about acceptance port type (Sec. 9.3). This is explictly an initiator side port type. Do we need to call this out very clearly since we have not had initiator side port types previously. This is somewhat called out at the start of sec. 9, but adding a comment here in 9.3 would be good. This is an optional mode of operation, so the initiator can choose this if it wants and can handle the more heavy-weight operation mode. - On creation operation, should we provide some general structure for faults (e.g. pointers to failed terms). We have at least two types of fault: could not understand the input, input understood, but not able to satisfy where this one could include pointers in to the input document plus some extensibility on the cause. This would be a bit of a hint, and does not imply anything concrete, or head down the slope of negotiation. **Action: this added to the comment list by Jim, would like to see a proposal here. - New section 8. Heiko might like to see some diagram, but perhaps that's one of those "primer" issues. - Termination dropped which gives people some concern. Is WS-RF termination good enough, and the terminate operation could fail or be delayed because the agreement is not "completed" yet. Further termination could be done as extension. We could define an extension on the resource lifetime termination operation saying that we cannot terminate now because the agreement is on-going. Do we advocate in the spec. that the agreement resource SHOULD live as long as the obligations associated with the agreement? Consensus on the list is that this makes sense. - For next week's call, we'll review updated document and see if we can mark some comments as completely resolved and inserted into the document.

2 1