Report from the ATF

Slide image generated by PowerPoint
ATF team

What is an Attribute?

Slide image generated by PowerPoint
Think of it this way:
Attributes define a pattern or short hand for messages that are supported by a service
Attribute MAY be used as a constraint on the values for input and output messages on certain operations
An Attribute MAY be viewed as an element of a "logical document" associated with the service
Some applications of Attributes:
Represent properties/values associated with the service
Represent values of a service's "metadata"
Represent the manageable properties of a service
Represent values of a service's "state"
Other things that sgg cannot currently imagine

What is Needed?

Slide image generated by PowerPoint
A single standard for modeling attributes at the interface level
A simple base mechanism to get/set values associated with attributes
But, doing this in a way that supports more sophisticated mechanisms
Get/Set subsets of all the attributes for a service in a single operation
Query mechanisms on the values of multiple attributes
The exact set of requirements are in the report
Other domains (eg OASIS WSDM, GGF) MAY define interface(s)/operation(s) that provide more sophisticated access to the values represented by the attribute

Why is this Needed?

Slide image generated by PowerPoint
Several vendors/users are passionate about this work
Several groups (eg GGF, WSDM) have independently defined approaches in this space, therefore impetus to standardize
Standardizing this in WSDL increases probability of interoperability on the definition and the simple operations
The aforementioned groups have stated preference that this concept be standardized in WSDL
Provides standard base upon which others can define more sophisticated operations over attributes

ATF Proposal

Slide image generated by PowerPoint
As with the last proposal (in Raleigh)
Model "attribute" as a first class component child of interface
Sibling of operation
What is different?
The base binding mechanism
Simpler, message pattern exchange approach

As with last time, Define Attribute Component on the Interface

Slide image generated by PowerPoint
<definitions>
  <interface>
    <attribute
        element="xs:QName"
        access= "read" | "write" | "read-write"? >
      <documentation />
    </attribute>*
  </interface>
</definitions>

Bindings define how to do simple get/set on the attribute's value

Slide image generated by PowerPoint
Define the way that bindings inform the consumers of the WSDL the message sets for get/set
This is analogous to the way that bindings inform WSDL consumers how to interpret operations
All bindings MUST define how they treat attributes that appear in the interface

SOAP/HTTP Binding

Slide image generated by PowerPoint
Get request
<soap:envelope>
  <soap:body>
    <wsdl:get-attribute name=xsd:QName/>
  </soap:body>
</soap:envelope>
Get Response
<soap:envelope>
  <soap:body ...>
     <xsd:QName> current value </xsd:QName>
  </soap:body>
</soap:envelope>
Possible fault messages:
UnknownAttribute
WriteOnlyAttribute

SOAP/HTTP Binding

Slide image generated by PowerPoint
Set request
<soap:envelope>
  <soap:body>
    <xsd:QName> new value </xsd:QName>
  </soap:body>
</soap:envelope>
Set Response
Currently (none)
We are considering that there should be a formal ack and the possibility of soap:fault messages
Lack of soap:fault message in response body to be interpreted as success

HTTP Binding

Slide image generated by PowerPoint
Get (use http get verb)
url?attribute-ns=
"xsd:anyURI"&attribute-localname="localName"
Value of the attribute (or error message) appears in body of http response
Set (use http post verb)
Body of the post contains new value:
<xsd:QName> new value </xsd:QName>
Set Response
Currently (none)
We are considering that there should be a formal ack and the possibility of fault messages and/or appropriate HTTP codes
Interpret the http header to determine success
Outline
  Notes