Report from the ATF
|
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 |
|
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 |
|
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 |
|
|
|
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 |
|
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> |
|
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 |
|
|
|
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 |
|
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 |
|
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 |
|
Notes