Report from the ATF

1. Report from the ATF ATF team

2. What is an Attribute? • 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

3. What is Needed? • 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

4. Why is this Needed? • 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

5. ATF Proposal • 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

6. As with last time, Define Attribute Component on the Interface <definitions> <interface> <attribute element="xs:QName" access= “read” | “write” | “read-write”? > <documentation /> </attribute>* </interface> </definitions>

7. Bindings define how to do simple get/set on the attribute’s value • 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

8. SOAP/HTTP Binding • 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

9. SOAP/HTTP Binding • 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

10. HTTP Binding • 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