Are attached. Note that the next call will be on Friday, 4/7, at the usual time of day. Reminder announcement to follow. --- Jim Minutes from the April 5, 2006 GRAAP Telecon Attendees --------- Toshi Nakata Jim Pruyne Chris Dabrowski Asit Dan Wolfgang Ziegler Heiko Ludwig Discussion ---------- - On updated termination diagram: * Asit to send a note on the mailing list to verify that we really have a transition from PendingAndTerminating to ObservedAndTerminating. None of us seem to be able to come up with a message sequence that would cause that to happen. * Asit will do an additional diagram to show the initial states that may be seen. - Spreadsheet row 10: Heiko to validate the schema as it relates to ServiceTermState and GuaranteeTermState. Heiko to post those changes back to the mailing list, and we'll determine follow-up steps on the next call (which is on Friday). - The next call will be on Friday, 4/7, same time of day!
Hi Jim: There is one editing error I made in P.36 Line 4-5 Could you please change These cases can be handled by this by allowing a domain-dependent sub-state of Terminated to indicate a normal completion prior to termination completion. =>(to) These cases can be handled by allowing a domain-dependent sub-state of Terminated to indicate a normal completion prior to termination completion. (ie delete the redundant 'by this')? Sorry for the trouble. Best Regards Toshi Jim Pruyne wrote:
Are attached. Note that the next call will be on Friday, 4/7, at the usual time of day. Reminder announcement to follow.
--- Jim
Done, the updated version with this change will be uploaded in a moment. --- Jim Toshiyuki Nakata wrote:
Hi Jim: There is one editing error I made in P.36 Line 4-5 Could you please change
These cases can be handled by this by allowing a domain-dependent sub-state of Terminated to indicate a normal completion prior to termination completion. =>(to)
These cases can be handled by allowing a domain-dependent sub-state of Terminated to indicate a normal completion prior to termination completion.
(ie delete the redundant 'by this')? Sorry for the trouble.
Best Regards Toshi
Jim Pruyne wrote:
Are attached. Note that the next call will be on Friday, 4/7, at the usual time of day. Reminder announcement to follow.
--- Jim
On Apr 05, Jim Pruyne modulated:
- On updated termination diagram: * Asit to send a note on the mailing list to verify that we really have a transition from PendingAndTerminating to ObservedAndTerminating. None of us seem to be able to come up with a message sequence that would cause that to happen.
I think this transition is implied by Toshi's "broker" example, unless we assert that there is some sort of transactional semantics in the protocol? If you make an offer to a broker, and it is pending in the broker because he has started to make offers to other service managers, your terminate request MAY arrive during the hazard window where the broker has started making commitments but has not received accepts from the subsidiary services yet. The client-to-broker agreement changes state to pending-terminating, and the broker can attempt to terminate the subsidiary agreements. However, depending on whether they terminate before or after they are accepted, the broker may want to communicate this "distributed acceptance" transition that occurred during the termination phase. I assume this has impact and is important to model in the event that the "penalties" are different depending on whether termination occurs before or after acceptance. The fundamental issue is that with pending agreements, the initiator has already committed in his offer message and he is at the mercy of the responder to decide if a termination request occurs before or after acceptance. Because of these hierarchical and asynchronous agreement scenarios, I think we have to make the termination request interaction also be asynchronous. Just as with the acceptance/rejection window, there is a window between when the termination request is received and the outcome is known. We can either delay the response, or model the uncertain intermediate state in the agreement state. I think we should do the latter to be consistent with how we have handled the acceptance/rejection window. For consistency, perhaps we should even go so far as to introduce two terminate request variants? One that is synchronous and delays the response, and one that responds early but leaves the agreement in an uncertain state? karl -- Karl Czajkowski karlcz@univa.com
Karl, It is understood that receiving a termination message (and upon provider acknowledgement), i) an agreement state transitions from a "Pending" to "PendingAndTerminating", and ii) the termination of service/agreement is not instantaneous (as you have elaborated). What we are trying to resolve here are the semantics of the states "PendingAndTerminating" and "ObservedAndTerminating", i.e., what are the obligations in delivering (service and) service quality, while an agreement is being terminated. Clearly, the options are a) No further obligations in delivering service quality (these states explicitly capture start of termination process, and the only difference between the above two states are historical, i.e., the state at which the termination message is received). b) Degraded quality of service (what are "observing"? Just how bad is it during termination process? Does client still expects any service quality? Are the BV specifications, i.e., penalties or preferences the same? Obvioulsy, further semantics has to be defined for specific domains for this to be meaningful.) and, c) Full quality of service, i.e., acknowledges start of termination process, but remains undefined when this will terminate, and service quality is fully observed. Again, we need more detailed specification to make sure there is a limit to this termination process, and/or, different BV assertions during this process. I think the simplest semantics (that doesn't require any further specification) is to assume upon starting the termination process the service quality obligations are no longer valid and observed. There is no easy way to have a consistent state across multi-tier services, i.e., where a service may depend on other autonomous services (as defined by its own set of agreements). Many years back, in the transaction community(HPTS), I argued for COYOTE (Cover Yourself Transaction Environment) principles, where service implementation and management issues are hidden from a client, even when a service is dependent on other services. The attached paper illustrates these principles. As a matter of fact, to further simplify the agreement states according to the above principles, we should assume termination of agreement (and not necessarily provider cleaning up and bookkeeping) is instantaneous, i.e., receiving the termination message takes the agreement state from "Pending" or "Observed" to "Terminated" state. In any case, if we choose the other two options, we have to specify further details in WS-Agreement specification for this transition to be meaningful. Regards. Asit Dan, Ph.D. SWG SOA Design Requirements Phone: (914) 766-1767 Internet: asit@us.ibm.com ICSOC 06 PC Chair (http://www.icsoc.org) Karl Czajkowski <karlcz@univa.com> Sent by: owner-graap-wg@ggf.org 04/06/2006 12:29 AM To Jim Pruyne <jim_pruyne@hp.com> cc GRAAP-WG <graap-wg@gridforum.org> Subject Re: [graap-wg] minutes from 4/5 telecon On Apr 05, Jim Pruyne modulated:
- On updated termination diagram: * Asit to send a note on the mailing list to verify that we really have a transition from PendingAndTerminating to ObservedAndTerminating. None of us seem to be able to come up with a message sequence that would cause that to happen.
I think this transition is implied by Toshi's "broker" example, unless we assert that there is some sort of transactional semantics in the protocol? If you make an offer to a broker, and it is pending in the broker because he has started to make offers to other service managers, your terminate request MAY arrive during the hazard window where the broker has started making commitments but has not received accepts from the subsidiary services yet. The client-to-broker agreement changes state to pending-terminating, and the broker can attempt to terminate the subsidiary agreements. However, depending on whether they terminate before or after they are accepted, the broker may want to communicate this "distributed acceptance" transition that occurred during the termination phase. I assume this has impact and is important to model in the event that the "penalties" are different depending on whether termination occurs before or after acceptance. The fundamental issue is that with pending agreements, the initiator has already committed in his offer message and he is at the mercy of the responder to decide if a termination request occurs before or after acceptance. Because of these hierarchical and asynchronous agreement scenarios, I think we have to make the termination request interaction also be asynchronous. Just as with the acceptance/rejection window, there is a window between when the termination request is received and the outcome is known. We can either delay the response, or model the uncertain intermediate state in the agreement state. I think we should do the latter to be consistent with how we have handled the acceptance/rejection window. For consistency, perhaps we should even go so far as to introduce two terminate request variants? One that is synchronous and delays the response, and one that responds early but leaves the agreement in an uncertain state? karl -- Karl Czajkowski karlcz@univa.com
On Apr 06, Asit Dan modulated:
Karl, It is understood that receiving a termination message (and upon provider acknowledgement), i) an agreement state transitions from a "Pending" to "PendingAndTerminating", and ii) the termination of service/agreement is not instantaneous (as you have elaborated).
What we are trying to resolve here are the semantics of the states "PendingAndTerminating" and "ObservedAndTerminating", i.e., what are the obligations in delivering (service and) service quality, while an agreement is being terminated. Clearly, the options are
a) No further obligations in delivering service quality (these states explicitly capture start of termination process, and the only difference between the above two states are historical, i.e., the state at which the termination message is received).
I think there is another semantics of concern about the implied obligations, i.e. the "payment" or "penalties". Let us assume in all cases that no service delivery guarantees will be expected once the client sends the terminate request. The issue I am trying to raise is that it is not just an atomic "state at which the termination is received". If I, as a broker, am in the process of computing acceptance when the termination is received, I would like to reserve the right to decide LATER whether I had accepted or rejected the agreement. I cannot make this decision instantaneously but must synchronize with a potentially complex brokering process. If allowed to by the specification, I could return immediately with the state I know (PendingAndTerminating) and still would be able to enter other states to reflect what happened. So, PendingAndTerminating->ObservedAndTerminating->Terminated would mean that I have decided, due to the non-deterministic things I was doing as a broker, that I was not able to complete your terminate request before accepting. I will bill you as having terminated an accepted agreement, i.e. in order to cover my own obligations with the services I was brokering (who may have accepted my offers before I could request termination). On the other hand, PendingAndTerminating->Terminated would mean that I have decided that I was able to complete your terminate request before accepting. I will bill you as having terminated a pending agreement, i.e. I do not have to cover obligations with brokered services because I either terminated them early or never even got around to making offers. The issue is that at the time I, the broker, receive your terminate request I do not really know the distributed state of my own brokering process and I cannot tell you whether I will have to go into ObservedAndTerminating or not. So, if we do not allow the PendingAndTerminating->ObservedAndTerminating transition, then I cannot respond to show any "terminating" state until I am able to synchronize my distributed process and make this determination. If you buy any of this, I think there is also an issue of having distinct final states (maybe sub-states?) for Terminated to encode the history of whether the agreement had been accepted or not. karl -- Karl Czajkowski karlcz@univa.com
Karl, very interesting. You are suggesting semantics of "PendingAndTerminating" and "ObservedAndTerminating" are identical to their counterparts (i.e., "Pending" and "Observed", respectively), in all aspects other than the acknowledgement of receiving a termination request. As a matter of fact once the termination decision is reached by the provider, the agreement state will transition from either of these states to "Terminated" state immediately (while internal clean up may be taking place). This also means if the termination request is rejected, then the states revert back to their counterpart states. With this interpretation, a transition is possible from "PendingAndTerminating" to "ObservedAndTerminating" until the termination decision is reached. Furthermore, in "ObservedAndTerminatating" state, the service quality must be observed just as in "Observed" state. If we agree with this interpretation, I can add new transitions from "PendingAndTerminating" and "ObservedAndTerminating" to their counterparts. We also need new text to clarify the transitions from these states to "Terminated" -- triggered by when termination decision is made, (and not when internal clean up may be taking place). Karl Czajkowski <karlcz@univa.com> wrote on 04/06/2006 11:39:14 AM:
I think there is another semantics of concern about the implied obligations, i.e. the "payment" or "penalties". Let us assume in all cases that no service delivery guarantees will be expected once the client sends the terminate request.
The issue I am trying to raise is that it is not just an atomic "state at which the termination is received". If I, as a broker, am in the process of computing acceptance when the termination is received, I would like to reserve the right to decide LATER whether I had accepted or rejected the agreement. I cannot make this decision instantaneously but must synchronize with a potentially complex brokering process. If allowed to by the specification, I could return immediately with the state I know (PendingAndTerminating) and still would be able to enter other states to reflect what happened.
So, PendingAndTerminating->ObservedAndTerminating->Terminated would mean that I have decided, due to the non-deterministic things I was doing as a broker, that I was not able to complete your terminate request before accepting. I will bill you as having terminated an accepted agreement, i.e. in order to cover my own obligations with the services I was brokering (who may have accepted my offers before I could request termination).
On the other hand, PendingAndTerminating->Terminated would mean that I have decided that I was able to complete your terminate request before accepting. I will bill you as having terminated a pending agreement, i.e. I do not have to cover obligations with brokered services because I either terminated them early or never even got around to making offers.
The issue is that at the time I, the broker, receive your terminate request I do not really know the distributed state of my own brokering process and I cannot tell you whether I will have to go into ObservedAndTerminating or not. So, if we do not allow the PendingAndTerminating->ObservedAndTerminating transition, then I cannot respond to show any "terminating" state until I am able to synchronize my distributed process and make this determination.
If you buy any of this, I think there is also an issue of having distinct final states (maybe sub-states?) for Terminated to encode the history of whether the agreement had been accepted or not.
Regards. Asit Dan, Ph.D. SWG SOA Design Requirements Phone: (914) 766-1767 Internet: asit@us.ibm.com ICSOC 06 PC Chair (http://www.icsoc.org)
Here is an updated foil with the following changes i) Added an initial transitioning state (that is not exposed to the initiator -- represented by the dashed lines) to clarify that exposed initial states can be "Pending", "Observed" or "Rejected". ii) Added new transitions from "PendingAndTerminating" and "PendingAndObserved" to their counterpart states (i.e., "Pending" and "Observed", respectively) when termination decision is rejected, and service is delivered with observed quality of service. owner-graap-wg@ggf.org wrote on 04/05/2006 11:12:30 AM:
* Asit will do an additional diagram to show the initial states that may be seen.
Regards. Asit Dan, Ph.D. SWG SOA Design Requirements Phone: (914) 766-1767 Internet: asit@us.ibm.com ICSOC 06 PC Chair (http://www.icsoc.org)
Hi: Asit thank you very much for the foil. I've included it in the updated doc. 1)I've added text OfferReceived is an internal state which is not exposed to the AgreementInitiator. * OfferReceived is an initial transition state (that is not exposed to the initiator -- represented by the dashed lines) to clarify that exposed initial states can be "Pending", "Observed" or "Rejected". It may be redundant to have two consecutive statements with almost the same meaning. If so, please choose which sentence should be dropped. I wasn't sure whether OfferReceived was a first class state. 2)I've added ObservedAndPending in the following statement. The Observed and ObservedAndPending states indicate that both parties are obligated with respect to the service and guarantee terms of the agreement. 3)In the explanation of Terminated state I've added "when termination decision is made." This state MAY follow Pending, PendingAndTerminating, Observed or ObservedAndTerminating when termination decision is made. 4)I have NOT added OfferReceived to the wsag:AgreementState as I understand OfferReceived is not visible to Agreement Initiator. Best Regards Toshi ----- Toshiyuki Nakata 中田 登志之 Executive 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)
-----Original Message----- From: owner-graap-wg@ggf.org [mailto:owner-graap-wg@ggf.org] On Behalf Of Asit Dan Sent: Friday, April 07, 2006 4:08 AM To: Jim Pruyne Cc: GRAAP-WG; owner-graap-wg@ggf.org Subject: Re: [graap-wg] minutes from 4/5 telecon
Here is an updated foil with the following changes i) Added an initial transitioning state (that is not exposed to the initiator -- represented by the dashed lines) to clarify that exposed initial states can be "Pending", "Observed" or "Rejected". ii) Added new transitions from "PendingAndTerminating" and "PendingAndObserved" to their counterpart states (i.e., "Pending" and "Observed", respectively) when termination decision is rejected, and service is delivered with observed quality of service.
owner-graap-wg@ggf.org wrote on 04/05/2006 11:12:30 AM:
* Asit will do an additional diagram to show the initial states that may be seen.
Regards. Asit Dan, Ph.D. SWG SOA Design Requirements Phone: (914) 766-1767 Internet: asit@us.ibm.com ICSOC 06 PC Chair (http://www.icsoc.org)
Regarding my todo: I didn't get to validating the schema in time prior to the Friday call. However, we do have the TermStateType in the schema. <xs:complexType name="TermStateType"> <xs:choice minOccurs="0"> <xs:any namespace="##other" processContents="lax"/> <!--Processing and Idle only as substates of Ready--> <xs:element name="Processing" type="wsag:InnerTermStateType"/> <xs:element name="Idle" type="wsag:InnerTermStateType"/> </xs:choice> <xs:attribute name="termName" type="xs:string"/> </xs:complexType> There is no separate GuaranteeTermStateType but a GuaranteeTermStateListType since they always come in lists in our port types. the idea being that, on a domain level, subtypes of different name spaces can be nested in. As to my understanding and as things look to me, this is ok. However, we should verify the whole schema, anyway. 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 675 8469 http://www.research.ibm.com/people/h/hludwig/ Jim Pruyne <jim_pruyne@hp.com> Sent by: owner-graap-wg@ggf.org 04/05/2006 11:12 AM To GRAAP-WG <graap-wg@gridforum.org> cc Subject [graap-wg] minutes from 4/5 telecon Are attached. Note that the next call will be on Friday, 4/7, at the usual time of day. Reminder announcement to follow. --- Jim Minutes from the April 5, 2006 GRAAP Telecon Attendees --------- Toshi Nakata Jim Pruyne Chris Dabrowski Asit Dan Wolfgang Ziegler Heiko Ludwig Discussion ---------- - On updated termination diagram: * Asit to send a note on the mailing list to verify that we really have a transition from PendingAndTerminating to ObservedAndTerminating. None of us seem to be able to come up with a message sequence that would cause that to happen. * Asit will do an additional diagram to show the initial states that may be seen. - Spreadsheet row 10: Heiko to validate the schema as it relates to ServiceTermState and GuaranteeTermState. Heiko to post those changes back to the mailing list, and we'll determine follow-up steps on the next call (which is on Friday). - The next call will be on Friday, 4/7, same time of day!
Hi Heiko: thank you very much about looking into the schema. My problem had been that in Sections 7.2 and Section 7.3 There are descriptions of pseudo schema for <wsag:ServiceTermState> and <wsag:GuaranteeTermState> but not in the actual schema. Is this OK? Best Regards Toshi Heiko Ludwig wrote:
Regarding my todo:
I didn't get to validating the schema in time prior to the Friday call. However, we do have the TermStateType in the schema.
<xs:complexType name="TermStateType"> <xs:choice minOccurs="0"> <xs:any namespace="##other" processContents="lax"/> <!--Processing and Idle only as substates of Ready--> <xs:element name="Processing" type="wsag:InnerTermStateType"/> <xs:element name="Idle" type="wsag:InnerTermStateType"/> </xs:choice> <xs:attribute name="termName" type="xs:string"/> </xs:complexType> There is no separate GuaranteeTermStateType but a GuaranteeTermStateListType since they always come in lists in our port types. the idea being that, on a domain level, subtypes of different name spaces can be nested in.
As to my understanding and as things look to me, this is ok. However, we should verify the whole schema, anyway.
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 675 8469 http://www.research.ibm.com/people/h/hludwig/
Jim Pruyne <jim_pruyne@hp.com> Sent by: owner-graap-wg@ggf.org 04/05/2006 11:12 AM
To GRAAP-WG <graap-wg@gridforum.org> cc
Subject [graap-wg] minutes from 4/5 telecon
Are attached. Note that the next call will be on Friday, 4/7, at the usual time of day. Reminder announcement to follow.
--- Jim
Minutes from the April 5, 2006 GRAAP Telecon
Attendees --------- Toshi Nakata Jim Pruyne Chris Dabrowski Asit Dan Wolfgang Ziegler Heiko Ludwig
Discussion ----------
- On updated termination diagram: * Asit to send a note on the mailing list to verify that we really have a transition from PendingAndTerminating to ObservedAndTerminating. None of us seem to be able to come up with a message sequence that would cause that to happen. * Asit will do an additional diagram to show the initial states that may be seen.
- Spreadsheet row 10: Heiko to validate the schema as it relates to ServiceTermState and GuaranteeTermState. Heiko to post those changes back to the mailing list, and we'll determine follow-up steps on the next call (which is on Friday).
- The next call will be on Friday, 4/7, same time of day!
Sorry: I might have not been too clear. To clarify: I've no problem with the actual XML schema. I'm only worried about whether it is OK to refer to non-defined constructs namely <wsag:ServiceTermState> and <wsag:GuaranteeTermState> in the pseudo-schema. If that is what you mean by the following I 'm quite happy.
the idea being that, on a domain level, subtypes of different name spaces can be nested in.
best regards Toshi Toshiyuki Nakata wrote:
Hi Heiko: thank you very much about looking into the schema.
My problem had been that in Sections 7.2 and Section 7.3 There are descriptions of pseudo schema for <wsag:ServiceTermState> and <wsag:GuaranteeTermState>
but not in the actual schema. Is this OK?
Best Regards Toshi
Heiko Ludwig wrote:
Regarding my todo:
I didn't get to validating the schema in time prior to the Friday call. However, we do have the TermStateType in the schema.
<xs:complexType name="TermStateType"> <xs:choice minOccurs="0"> <xs:any namespace="##other" processContents="lax"/> <!--Processing and Idle only as substates of Ready--> <xs:element name="Processing" type="wsag:InnerTermStateType"/> <xs:element name="Idle" type="wsag:InnerTermStateType"/> </xs:choice> <xs:attribute name="termName" type="xs:string"/> </xs:complexType> There is no separate GuaranteeTermStateType but a GuaranteeTermStateListType since they always come in lists in our port types. the idea being that, on a domain level, subtypes of different name spaces can be nested in.
As to my understanding and as things look to me, this is ok. However, we should verify the whole schema, anyway.
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 675 8469 http://www.research.ibm.com/people/h/hludwig/
Jim Pruyne <jim_pruyne@hp.com> Sent by: owner-graap-wg@ggf.org 04/05/2006 11:12 AM
To GRAAP-WG <graap-wg@gridforum.org> cc
Subject [graap-wg] minutes from 4/5 telecon
Are attached. Note that the next call will be on Friday, 4/7, at the usual time of day. Reminder announcement to follow.
--- Jim
Minutes from the April 5, 2006 GRAAP Telecon
Attendees --------- Toshi Nakata Jim Pruyne Chris Dabrowski Asit Dan Wolfgang Ziegler Heiko Ludwig
Discussion ----------
- On updated termination diagram: * Asit to send a note on the mailing list to verify that we really have a transition from PendingAndTerminating to ObservedAndTerminating. None of us seem to be able to come up with a message sequence that would cause that to happen. * Asit will do an additional diagram to show the initial states that may be seen.
- Spreadsheet row 10: Heiko to validate the schema as it relates to ServiceTermState and GuaranteeTermState. Heiko to post those changes back to the mailing list, and we'll determine follow-up steps on the next call (which is on Friday).
- The next call will be on Friday, 4/7, same time of day!
Toshi, there are Elements (contained in the list types) with these respective names. No types, though. Hence, I think describing the element it ok. 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 675 8469 http://www.research.ibm.com/people/h/hludwig/ Toshiyuki Nakata <nakata@mtg.biglobe.ne.jp> 04/07/2006 11:23 AM Please respond to t-nakata@cw.jp.nec.com To t-nakata@cw.jp.nec.com cc Heiko Ludwig/Watson/IBM@IBMUS, Jim Pruyne <jim_pruyne@hp.com>, GRAAP-WG <graap-wg@gridforum.org>, owner-graap-wg@ggf.org Subject Re: [graap-wg] minutes from 4/5 telecon Sorry: I might have not been too clear. To clarify: I've no problem with the actual XML schema. I'm only worried about whether it is OK to refer to non-defined constructs namely <wsag:ServiceTermState> and <wsag:GuaranteeTermState> in the pseudo-schema. If that is what you mean by the following I 'm quite happy.
the idea being that, on a domain level, subtypes of different name spaces can be nested in.
best regards Toshi Toshiyuki Nakata wrote:
Hi Heiko: thank you very much about looking into the schema.
My problem had been that in Sections 7.2 and Section 7.3 There are descriptions of pseudo schema for <wsag:ServiceTermState> and <wsag:GuaranteeTermState>
but not in the actual schema. Is this OK?
Best Regards Toshi
Heiko Ludwig wrote:
Regarding my todo:
I didn't get to validating the schema in time prior to the Friday call. However, we do have the TermStateType in the schema.
<xs:complexType name="TermStateType"> <xs:choice minOccurs="0"> <xs:any namespace="##other" processContents="lax"/> <!--Processing and Idle only as substates of Ready--> <xs:element name="Processing" type="wsag:InnerTermStateType"/> <xs:element name="Idle" type="wsag:InnerTermStateType"/> </xs:choice> <xs:attribute name="termName" type="xs:string"/> </xs:complexType> There is no separate GuaranteeTermStateType but a GuaranteeTermStateListType since they always come in lists in our port types. the idea being that, on a domain level, subtypes of different name spaces can be nested in.
As to my understanding and as things look to me, this is ok. However, we should verify the whole schema, anyway.
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 675 8469 http://www.research.ibm.com/people/h/hludwig/
Jim Pruyne <jim_pruyne@hp.com> Sent by: owner-graap-wg@ggf.org 04/05/2006 11:12 AM
To GRAAP-WG <graap-wg@gridforum.org> cc
Subject [graap-wg] minutes from 4/5 telecon
Are attached. Note that the next call will be on Friday, 4/7, at the usual time of day. Reminder announcement to follow.
--- Jim
Minutes from the April 5, 2006 GRAAP Telecon
Attendees --------- Toshi Nakata Jim Pruyne Chris Dabrowski Asit Dan Wolfgang Ziegler Heiko Ludwig
Discussion ----------
- On updated termination diagram: * Asit to send a note on the mailing list to verify that we really have a transition from PendingAndTerminating to ObservedAndTerminating. None of us seem to be able to come up with a message sequence that would cause that to happen. * Asit will do an additional diagram to show the initial states that may be seen.
- Spreadsheet row 10: Heiko to validate the schema as it relates to ServiceTermState and GuaranteeTermState. Heiko to post those changes back to the mailing list, and we'll determine follow-up steps on the next call (which is on Friday).
- The next call will be on Friday, 4/7, same time of day!
Heiko: Thank you very much for checking, Just to make sure. How about expressions like, /wsag:ServiceTermState This element contains the state of a service term, one of the following top-level elements: in P.37 or expressions like: /wsag:ServiceTermState/wsag:NotReady in P.37 compared to /wsag:ServiceTermStateList/wsag:NotReady in P.49? Best Regards Toshi ----- Toshiyuki Nakata 中田 登志之 Executive 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)
-----Original Message----- From: Heiko Ludwig [mailto:hludwig@us.ibm.com] Sent: Saturday, April 08, 2006 5:25 AM To: t-nakata@cw.jp.nec.com Cc: GRAAP-WG; Jim Pruyne; owner-graap-wg@ggf.org; t-nakata@cw.jp.nec.com Subject: Re: [graap-wg] minutes from 4/5 telecon
Toshi,
there are Elements (contained in the list types) with these respective names. No types, though. Hence, I think describing the element it ok.
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 675 8469 http://www.research.ibm.com/people/h/hludwig/
Toshiyuki Nakata <nakata@mtg.biglobe.ne.jp>
04/07/2006 11:23 AM Please respond to t-nakata@cw.jp.nec.com
To t-nakata@cw.jp.nec.com cc Heiko Ludwig/Watson/IBM@IBMUS, Jim Pruyne <jim_pruyne@hp.com>, GRAAP-WG <graap-wg@gridforum.org>, owner-graap-wg@ggf.org Subject Re: [graap-wg] minutes from 4/5 telecon
Sorry: I might have not been too clear. To clarify: I've no problem with the actual XML schema. I'm only worried about whether it is OK to refer to non-defined constructs namely <wsag:ServiceTermState> and <wsag:GuaranteeTermState> in the pseudo-schema.
If that is what you mean by the following I 'm quite happy.
the idea being that, on a domain level, subtypes of different name spaces can be nested in.
best regards Toshi
Toshiyuki Nakata wrote:
Hi Heiko: thank you very much about looking into the schema.
My problem had been that in Sections 7.2 and Section 7.3 There are descriptions of pseudo schema for <wsag:ServiceTermState> and <wsag:GuaranteeTermState>
but not in the actual schema. Is this OK?
Best Regards Toshi
Heiko Ludwig wrote:
Regarding my todo:
I didn't get to validating the schema in time prior to the Friday call. However, we do have the TermStateType in the schema.
<xs:complexType name="TermStateType"> <xs:choice minOccurs="0"> <xs:any namespace="##other" processContents="lax"/> <!--Processing and Idle only as substates of Ready--> <xs:element name="Processing" type="wsag:InnerTermStateType"/> <xs:element name="Idle" type="wsag:InnerTermStateType"/> </xs:choice> <xs:attribute name="termName" type="xs:string"/> </xs:complexType> There is no separate GuaranteeTermStateType but a GuaranteeTermStateListType since they always come in lists in our port types. the idea being that, on a domain level, subtypes of different name spaces can be nested in.
As to my understanding and as things look to me, this is ok. However, we should verify the whole schema, anyway.
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 675 8469 http://www.research.ibm.com/people/h/hludwig/
Jim Pruyne <jim_pruyne@hp.com> Sent by: owner-graap-wg@ggf.org 04/05/2006 11:12 AM
To GRAAP-WG <graap-wg@gridforum.org> cc
Subject [graap-wg] minutes from 4/5 telecon
Are attached. Note that the next call will be on Friday, 4/7, at the usual time of day. Reminder announcement to follow.
--- Jim
Minutes from the April 5, 2006 GRAAP Telecon
Attendees --------- Toshi Nakata Jim Pruyne Chris Dabrowski Asit Dan Wolfgang Ziegler Heiko Ludwig
Discussion ----------
- On updated termination diagram: * Asit to send a note on the mailing list to verify that we really have a transition from PendingAndTerminating to ObservedAndTerminating. None of us seem to be able to come up with a message sequence that would cause that to happen. * Asit will do an additional diagram to show the initial states that may be seen.
- Spreadsheet row 10: Heiko to validate the schema as it relates to ServiceTermState and GuaranteeTermState. Heiko to post those changes back to the mailing list, and we'll determine follow-up steps on the next call (which is on Friday).
- The next call will be on Friday, 4/7, same time of day!
participants (6)
-
Asit Dan -
Heiko Ludwig -
Jim Pruyne -
Karl Czajkowski -
Toshiyuki Nakata -
Toshiyuki Nakata