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
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)
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
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:
<xs:group name="typeDefParticle"> <xs:annotation> <xs:documentation> 'complexType' uses this</xs:documentation></xs:annotation> <xs:choice> <xs:element name="group" type="xs:groupRef"/> <xs:element ref="xs:all"/> <xs:element ref="xs:choice"/> <xs:element ref="xs:sequence"/> </xs:choice> </xs:group> <xs:group name="nestedParticle"> <xs:choice> <xs:element name="element" type="xs:localElement"/> <xs:element name="group" type="xs:groupRef"/> <xs:element ref="xs:choice"/> <xs:element ref="xs:sequence"/> <xs:element ref="xs:any"/> </xs:choice> </xs:group> 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@us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/
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@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 07/13/2005 03:30 PM To t-nakata@cw.jp.nec.com cc GRAAP-WG <graap-wg@gridforum.org> 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
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)
participants (3)
-
Heiko Ludwig -
Jim Pruyne -
Toshiyuki Nakata