Inconsistencies in the WS-Agreement Specification (GFD.107) and WS-Agreement Schema (ws-agreement.xsd)

Dear Ladies and Gentlemen, I'm currently workin on an OWL based ontology for Service Level Agreements based on WS-Agreement for my bachelor thesis at Karlsruhe Institut of Technology (KIT). Studying the standard you provided as well as the XML schema, I faced some (imo) inconsistencies. In the written part of your standard, you do do repeatedly define terms comprising *one or more* service terms (cardinality 1..*) and *zero or more* guarantee terms (cardinality 0..*)" (page 4, page 14). Therefore I interprete that a single GuaranteeTerm without any ServiceDescriptionTerm / ServiceReference / ServiceProperty ain't intended to be possible. Whatever, the coding integrated in the standard document (page 17/18) as well as your provided ws-agreement.xsd allow terms comprising ONLY a single GuaranteeTerm. Another point is that in the textual description, you engage ServiceTerm as super class of ServiceDescriptionTerm, ServiceReference and ServiceProperty while the entity ServiceTerm ain't used in you example coding (page 17/18) nor in the provided XSD. My question is now whether the GFD provided implementation (no ServiceTerm class, single GuaranteeTerm possible) or the standards' text shall be referenced to for futur work. Attached you can find some pseudocode to underline my thoughts. Best regards, Knud Mikkat -- Knud MIKKAT Student der Informationswirtschaft (B.Sc.) Karlsruher Institut für Technologie (KIT) <!-- wsag:Terms without ServiceTerm --> <wsag:Terms> <wsag:All> { <wsag:All> wsag:TermCompositorType </wsag:All> | <wsag:OneOrMore> wsag:TermCompositorType </wsag:OneOrMore> | <wsag:ExactlyOne> wsag:TermCompositorType </wsag:ExactlyOne> | <wsag:All> { <wsag:ServiceDescriptionTerm> wsag:ServiceDescriptionTermType </wsag:ServiceDescriptionTerm> | <wsag:ServiceReference> wsag:ServiceReferenceType </wsag:ServiceReference> | <wsag:ServiceProperties> wsag:ServicePropertiesType </wsag:ServiceProperties> } + { <wsag:GuaranteeTerm> wsag:GuaranteeTermType </wsag:GuaranteeTerm> } * </wsag:All> } + <wsag:All> </wsag:Terms> <!-- wsag:Terms with ServiceTerm --> <wsag:Terms> <wsag:All> { <wsag:All> wsag:TermCompositorType </wsag:All> | <wsag:OneOrMore> wsag:TermCompositorType </wsag:OneOrMore> | <wsag:ExactlyOne> wsag:TermCompositorType </wsag:ExactlyOne> | <wsag:All> { <wsag:ServiceTerm> wsag:ServiceTermType </wsag:ServiceTerm> } + { <wsag:GuaranteeTerm> wsag:GuaranteeTermType </wsag:GuaranteeTerm> } * </wsag:All> } + <wsag:All> </wsag:Terms> <wsag:ServiceDescriptionTerm rdf:subClassOf wsag:ServiceTerm /> <wsag:ServiceReference rdf:subClassOf wsag:ServiceTerm /> <wsag:ServiceProperty rdf:subClassOf wsag:ServiceProperty />

Dear Knud,
In the written part of your standard, you do do repeatedly define terms comprising *one or more* service terms (cardinality 1..*) and *zero or more* guarantee terms (cardinality 0..*)" (page 4, page 14). Therefore I interprete that a single GuaranteeTerm without any ServiceDescriptionTerm / ServiceReference / ServiceProperty ain't intended to be possible. Whatever, the coding integrated in the standard document (page 17/18) as well as your provided ws-agreement.xsd allow terms comprising ONLY a single GuaranteeTerm.
That is correct. Usually an agreement only makes sense when it includes a description of the service that is to be provided. Additionally, you can define measurable properties that are associated with the service (service properties) and guarantees that are defined using the service properties. Even though the WS-Agreement schema does not enforce this incremental structure, the textual description illustrates this mechanism. Personally, I think that this point (cardinality of service description and guarantee terms) should be addressed during the domain specific template design, not in the specification itself. Since templates can include creation constraints to define the structure of an agreement in a fine granular way, this mechanism can be used to ensure that a specific agreement MUST include one service description term and a guarantee.
Another point is that in the textual description, you engage ServiceTerm as super class of ServiceDescriptionTerm, ServiceReference and ServiceProperty while the entity ServiceTerm ain't used in you example coding (page 17/18) nor in the provided XSD.
The ServiceTerm type is defined as an abstract type. It is the abstract base class for the service description terms, service properties, and guarantee terms. The example code at the mentioned pages illustrates the usage of the concrete types. Therefore, the abstract base type is not part of the pseudo code. Best regards, Oliver -----Ursprüngliche Nachricht----- Von: graap-wg-bounces@ogf.org [mailto:graap-wg-bounces@ogf.org] Im Auftrag von Knud Mikkat Gesendet: Donnerstag, 15. April 2010 16:48 An: graap-wg@ogf.org Betreff: [GRAAP-WG] Inconsistencies in the WS-Agreement Specification (GFD.107) and WS-Agreement Schema (ws-agreement.xsd) Dear Ladies and Gentlemen, I'm currently workin on an OWL based ontology for Service Level Agreements based on WS-Agreement for my bachelor thesis at Karlsruhe Institut of Technology (KIT). Studying the standard you provided as well as the XML schema, I faced some (imo) inconsistencies. In the written part of your standard, you do do repeatedly define terms comprising *one or more* service terms (cardinality 1..*) and *zero or more* guarantee terms (cardinality 0..*)" (page 4, page 14). Therefore I interprete that a single GuaranteeTerm without any ServiceDescriptionTerm / ServiceReference / ServiceProperty ain't intended to be possible. Whatever, the coding integrated in the standard document (page 17/18) as well as your provided ws-agreement.xsd allow terms comprising ONLY a single GuaranteeTerm. Another point is that in the textual description, you engage ServiceTerm as super class of ServiceDescriptionTerm, ServiceReference and ServiceProperty while the entity ServiceTerm ain't used in you example coding (page 17/18) nor in the provided XSD. My question is now whether the GFD provided implementation (no ServiceTerm class, single GuaranteeTerm possible) or the standards' text shall be referenced to for futur work. Attached you can find some pseudocode to underline my thoughts. Best regards, Knud Mikkat -- Knud MIKKAT Student der Informationswirtschaft (B.Sc.) Karlsruher Institut für Technologie (KIT)
participants (2)
-
Knud Mikkat
-
Oliver Wäldrich