----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig@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@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@us.ibm.com, tel. +1 914 784 7160, mob. +1 646 236 9453 http://www.research.ibm.com/people/h/hludwig/ Jim Pruyne <pruyne@hpl.hp.com> Sent by: owner-graap-wg@ggf.org 04/13/2005 12:21 PM To GRAAP-WG <graap-wg@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.