This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/go/projects.ggf-editor/discussion.rec_ws_agreement_spec_1.sorry_for_the_late_post at Sun, 06 Nov 2022 09:02:43 GMT SourceForge : Post

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Project: Editor     Discussion > REC: WS-Agreement Spec > sorry for the late post > List of Posts
Forum Topic - sorry for the late post: (6 Items)
View:  as 
 
 
sorry for the late post
We are planning to implement WS-Agreement partially, so we 
need to understand the spec sufficiently.

We have the following questions: 

-9
I have a question about the simple client-server scenario.
In order that the client can monitor the agreement, he/she must know the EPR 
of the AgreementState in the server side. How can he/she get the EPR?

- 9.1.1.2, 9.2.1.2
According to the (Pending) Agreement Factory Port Type WSDL, 
the content of wsag:createdAgreementEPR should be as follows.
<wsag:createdAgreementEPR>
  wsa:EndpointReferenceType
</wsag:createdAgreementEPR>

- 9.4.5
wsag:AgreementServiceReferenceList element specifies a list of service 
references. However, the Agreement types schema says that the element can have 
only one service reference.

- 10
According to the note at the top of this chapter, it is suggested 
(not mandated) that agreement services implement WS-ServiceGroup.
However, Agreement Factory Port Type WSDL says that the portType must have
at least one wssg:MembershipContentRule resource property.
That is, the implemetation of wsag:AgreementFactory portType must implement
WS-ServiceGroup as well, which is a contradition.

- 10
The WS-ServiceGroup schema is imported in Agreement Acceptance Port Type WSDL, 
which is not necessary.

- 10
The Agreement Port Type defines wssg:MembershipContentRule and wssg:Entry
as its resource properties. Why must this portType inherit WS-ServiceGroup?
What kind of list does agreement manage?

- Appendix 1
The element declaration of wsag:Template and its data type definition are not
found in the XML schemas.
group response
Thanks for the comment.  We've updated the specification to reflect the changes you suggest.
Re: sorry for the late post
I had a wrong comment.

> - Appendix 1 
> The element declaration of wsag:Template and its data type definition are not 
> found in the XML schemas. 

I found the element declaration of wsag:Template and its data type definition 
in the schema. Sorry to bother you.

Regards, 

Yuichiro Yonebayashi
Ascade, Inc.
More ...
More comments ...

1. Most of the element/attribute names defined in the spec begin with 
upper case, but the followings lower case. They should begin with upper case.

 - wsag:initiatorAgreementEPR (in 9.1.1.1, 9.2.1.1, Appendix 1)
 - wsag:createdAgreementEPR (in 9.1.1.2, 9.2.1.2, Appendix 1)
 - wsag:agreementAcceptanceEPR (in 9.2.1.1, Appendix 1)
 - wsag:agreementProperties (element declaration in p.66 and element reference in p.67)
 - wsag:***/@termName (in 9.5.2, 9.5.3, Appendix 1)

Note that the message element names (such as "createAgreementInput") begin with 
lower case, which may be possibly allowable.

2. Why are the two prefixes (xsd and xs) are used for the namespace 
"http://www.w3.org/2001/XMLSchema"? 
That is inconvenient for searching in the specification.

3. In the explanation of /wsag:GuaranteeTerm/wsag:ServiceScope element in 4.2.6.1.
> A service scope describes to what service element specifically 
> a service applies.
  ^^^^^^^^^^^^^^^^^
I wonder if "a guarantee term applies" is correct.

4. In chapter 5, section 5.1 and Appendix 2, "wsag:template" should be replaced 
by "wsag:Template".

5. In 5.1.1, 
/wsag:Item/Location  ->  /wsag:Item/wsag:Location
/wsag:Item/ItemConstraint  ->  /wsag:Item/wsag:ItemConstraint

6. In the XML schema in Appendix 1, attribute definition should be corrected 
as follows:
<xs:attribute name="name" type="xs:string"/>
->
<xs:attribute name="Name" type="xs:string"/> 

Regards, 
 
Yuichiro Yonebayashi 
Ascade, Inc.
Additional comment
Let me add a comment.

Following is an excerpt from the Agreement Types Schema.

<xs:element name="Terms" type="wsag:TermTreeType"/>
<xs:complexType name="TermTreeType">
  <xs:sequence>
    <xs:element ref="wsag:All" minOccurs="0"/>
  </xs:sequence>
</xs:complexType>

<xs:element name="All" type="wsag:TermCompositorType"/>
<xs:complexType name="TermCompositorType">
  <xs:sequence>
    <xs:choice maxOccurs="unbounded">
      <xs:element name="ExactlyOne" type="wsag:TermCompositorType"/>
      <xs:element name="OneOrMore" type="wsag:TermCompositorType"/>
      <xs:element ref="wsag:All"/>
      <xs:element name="ServiceDescriptionTerm"
                  type="wsag:ServiceDescriptionTermType"/>
      <xs:element name="ServiceReference"
                  type="wsag:ServiceReferenceType"/>
      <xs:element name="ServiceProperties"
                  type="wsag:ServicePropertiesType"/>
      <xs:element name="GuaranteeTerm"
                  type="wsag:GuaranteeTermType"/>
    </xs:choice>
  </xs:sequence>
</xs:complexType>

According to the 3rd paragraph of chapter 1, An agreement includes one or more 
service terms. But the schema above allows an agreement with no 
wsag:ServiceDescriptionTerm, no wsag:ServiceReference, and no wsag:ServiceProperties.
In my opinion, such an agreement may be allowed in the case that it is clear 
(between the initiator and the responder) which service the agreement describes.

Regards, 

Yuichiro Yonebayashi
Ascade, Inc.
Re: sorry for the late post
Sorry again, 

let me fix a typo.

- 10 
...
WS-ServiceGroup as well, which is a contradition. 
->
...
WS-ServiceGroup as well, which is a contradiction. 

Regards, 

Yuichiro Yonebayashi
Ascade Inc.

 
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/go/projects.ggf-editor/discussion.rec_ws_agreement_spec_1.sorry_for_the_late_post at Sun, 06 Nov 2022 09:02:43 GMT