Suggested WSDL and XSD modification

6 Oct 2006

      Hi,

as you know, I'm implementing the WSAG on top of GT4. I've found some 
issues with the current WSDL and schema definition and suggest the 
corresponding modification is made. There are three kinds of issues that 
are concerened:
(1) in AgreementState.wsdl

            <xs:complexType name="AgreementStatePropertiesType">
                <xs:sequence>
                    <xs:element ref="wsag:AgreementState" />
                    <xs:element ref="wsag:GuaranteeTermStateList" />
                    <xs:element ref="wsag:ServiceTermStateList" />
                </xs:sequence>
            </xs:complexType>
should be
            <xs:complexType name="AgreementStatePropertiesType">
                <xs:sequence>
                    <xs:element ref="wsag:AgreementState" />
                    <xs:element ref="wsag:GuaranteeTermState" 
minOccurs="0" maxOccurs="unbounded"/>
                    <xs:element ref="wsag:ServiceTermState" 
minOccurs="0" maxOccurs="unbounded"/>
                </xs:sequence>
            </xs:complexType>
It avoids the definition of additional type wsag:GuaranteeTermStateList 
and wsag:ServiceTermStateList. It is more consistent with the WSRF 
specification by giving individual access to each of the 
GuaranteeTermState and ServiceTermState items.

Correspondingly, the current definition of wsag:GuaranteeTermStateList 
and wsag:ServiceTermStateList in agreement_state_types.xsd :
    <xsd:element name="GuaranteeTermStateList" 
type="wsag:GuaranteeTermStateListType" />
    <xsd:element name="ServiceTermStateList" 
type="wsag:ServiceTermStateListType" />
should correspondingly be modified into
    <xsd:element name="GuaranteeTermState" 
type="wsag:GuaranteeTermStateType" />
    <xsd:element name="ServiceTermState" type="wsag:ServiceTermStateType" />

(2) Related with issue (1), I stongly suggest wsag:AgreementStateType 
and wsag:GuaranteeTermStateType and wsag:ServiceTermStateType defined in 
the way as the attached agreement_state_types.xsd .
Take ServiceTermState for example. Briefly speaking, it defines the 
ServiceTermState as a global element to support issue(1). AND, the 
ServiceTermStateType extends the TermStateType and the corresponding 
type of state is defined as an attribute extension.

---original---
    <xsd:complexType name="GuaranteeTermStateListType">
        <xsd:choice maxOccurs="unbounded">
            <xsd:element name="NotDetermined" type="wsag:TermStateType" />
            <xsd:element name="Fulfilled" type="wsag:TermStateType" />
            <xsd:element name="Violated" type="wsag:TermStateType" />
        </xsd:choice>
    </xsd:complexType>

---suggestion---
    <xsd:element name="ServiceTermState" type="wsag:ServiceTermStateType" />
    <xsd:complexType name="ServiceTermStateType">
        <xsd:complexContent>
            <xsd:extension base="wsag:TermStateType">
                <xsd:attribute name="state">
                    <xsd:simpleType>
                        <xsd:restriction base="xsd:string">
                            <xsd:enumeration value="NotReady" />
                            <xsd:enumeration value="Ready" />
                            <xsd:enumeration value="Completed" />
                        </xsd:restriction>
                    </xsd:simpleType>
                </xsd:attribute>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

This has several practical advantages. First, if the state element has 
sub elements, the change of state will result into complicated XML 
process or Java object operations in the old definition and with the 
suggested definition you only need to change the state parameter. 
Second, both Globus and Axis 1.x has problem in stub generation for 
xsd:choice maxOccurs="unbounded". Third, this definition is more 
consistent with the style of definition in agreement_types.xsd (look at 
the different term type definitions there).

After all,  this change does not result into the loss of constraint 
power and do not require modification of the current specification 
except for the XSD file itself.

Please see the attached agreement_state_types.xsd file for modifications 
to other types.

(3) in one of my previous posts, I asked about the exact meaning of 
wsag:AgreementServiceReferenceList as a sub element of 
wsag:AgreementProperties and got no answer yet.
It seems to be a duplication of the information in ServiceReference 
element of ServiceDescriptionTerm, which is another sub element of 
wsag:AgreementProperties. If I'm correct, then it should be removed.

Correct me if I'm wrong. And if you agree, please vote.

Best regards,
Tianchao Li

==============================
Institut fuer Informatik, TU Muenchen
Germany
http://www.lrr.in.tum.de/~lit

Tianchao Li

Tianchao Li

tags

participants (1)