Thanks for the comment.  We've updated the specification to reflect the changes you suggest.

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 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.

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.

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.