- From: Steve Graham <sggraham@us.ibm.com>
- Date: Sat, 19 Jul 2003 13:23:59 -0400
- To: public-ws-desc-state@w3.org
ATFers: ServiceData has the following information items: - name - type - nillable - minOccurs, maxOccurs - mutability - modifiability @name and @type are the same in the attributes proposal and OGSI serviceData. @nillable could be an OGSI extension. That is, OGSI could add an ogsi namespace @minOccurs and @maxOccurs illuminates perhaps a conceptual gap in the modeling approach. In OGSI the type of the SDE reflected the type of an individual value. The SDE itself could take multiple values. The analogy was more along the line of an SDE being an xsd:element definition. With the approach suggested here, the type of the WSDL 1.2 attribute would model an outer “container”. Perhaps an example would be illuminating: in OGSI I could specify: <gwsdl:portType name=”somePT” …> <sd:serviceData name=”sd1” type=”xsd:integer” minOccurs=”1” maxOccurs=”5”/> <sd:serviceData name=”sd2” type=”tns:foo” minOccurs=”1” maxOccurs=”1” /> And this would imply that the service implementing the portType would have state represented by a “logical” XML document that could look like: <sd:serviceDataValues> <sd1>1</sd1> <sd1>2</sd1> <sd1>3</sd1> <sd1>4</sd1> <sd1>5</sd1> <sd2> <tns:foo>bar</tns:foo> </sd2> </sd:serviceDataValues> … </gwsdl:portType> The term “logical” is used because the actual SDE values did not have to be stored in XML, but that the service implementation was obligated to be able to support this notion. It is particularly important to support XPath queries against the entire state. So the equivalent construct with the attributes proposal would look like: <wsdl:interface name=”somePT” …> <attribute name=”sd1” type=”tns:sd1Container”> <attribute name=”sd2” type=”tns:foo> … </wsdl:interface> where sd1Container would be defined as: <xsd:element name="sd1Container"> <xsd:complexType > <xsd:sequence> <xsd:element name="sd1" type="xsd:integer" minOccurs="1" maxOccurs="5"/> </xsd:sequence> </xsd:complexType> </xsd:element> and sd2 can be modeled directly since it does not represent a repeating group of values. This has the additional burden of the designer defining the container element for sd1. Furthermore, there is no notion of a “containment” element for all the values of the state. It is somewhat harder, but as we will see, not impossible to write XPath queries across state. @mutability could be an OGSI extension. @modifiability essentially maps to the @readonly. Note: that we could define a child element of the attribute element to support “default” values or static values. We have a facility like this in OGSI serviceData. The point has been raised by Savas that properties and features could be used [1]. However I personally would like to see an example of this, and make sure that the “static” values have close affinity to the declaration of the attribute. Looking at the findServiceData and setServiceData operations in the GridService portType, I would assert that these operations are much more sophisticated than simple get/set. The operations act across individual SDEs and would therefore be the subject of an OGSI-specific interface. We need to make sure we can define the conceptual model for attributes properly that allows us to build the necessary conceptual model. Note: there does not seem to be much support for “dynamic” serviceData elements. [1] http://lists.w3.org/Archives/Public/public-ws-desc-state/2003Jul/0035.html ++++++++ Steve Graham sggraham@us.ibm.com (919)254-0615 (T/L 444) STSM, On Demand Architecture ++++++++
Received on Saturday, 19 July 2003 13:25:47 UTC