RE: Preliminary report from the Attributes Task force

Comments on "Report from the Attributes Task Force"

This document presents the views of Savas Parastatidis and Jim Webber on
the "Report from the Attributes Task Force." We are sending this
document to the same mailing lists the report made its first appearance.
We understand that as non-members of the task force we could not have
participated in the voting/editing process for this report. Although the
discussions were always open through the task force's mailing list we
felt that we should present our views to the WSDL community by
discussing the report point-by-point (our comments appear in black...
apologies for sending HTML).

 


Problem:


The Attributes Task Force was chartered to consider the requirements for
modeling attributes, or elements of publicly available state of a Web
service, in WSDL.

Nowhere in the Web Services Architecture (WSA) the concept of "publicly
available state" of a Web Service is defined. We believe that there is
no problem that needs to be addressed. We understand the need for giving
the flexibility to Web Service interface designers in various
applications domains (e.g., Grid) to define ways of exchanging messages
that result to an "attribute" operation. However, we believe that unless
"attribute" and "Web Service state" have specific meanings within the
WSA, WSDL can only provide a wsdl:attribute element as a specialisation
of message description and nothing more.

 

We have gathered requirements and explored various alternatives and
precedents in the industry, including: WebDAV, CORBA IDL attributes and
OGSI ServiceData.

 

This document summarizes our analysis and a recommendation to the W3C
Web Service Description Working Group.


Requirements:


The following are the requirements gathered by the Attributes Task
Force[1]. The solution must allow or support:

 

1.      The user should be able to know what their permissions are on
attributes before trying to access the attribute.

We believe that this requirement is orthogonal to WSDL. The way access
to a wsdl:attribute is restricted should not differ from that of a
wsdl:operation. There are other, security-related, specifications that
deal with access policies and permissions. Although the report concludes
that this is not addressed, we believe that this shouldn't even be a
requirement.

2.      Query across attributes (in one service) by some query language.

Query across attributes of a Web Service would make sense only if the
WSA defined the semantics of what it means for a service to have state
and attributes. 

 

3.      The user to know a (potentially partial) list of attributes at
design time. This implies that additional attributes may appear at
runtime. OGSI calls this facility "dynamic serviceData".

This suggests that the interface of a service may change at runtime. We
believe that this is bad practise and should not be encouraged.
Currently, there is nothing in the WSDL specification to restrict tool
vendors from changing the operations in the public interface of a Web
Service after that service has been deployed. However, a change to an
interface should be accompanied by a change in the namespace in which
that interface is defined. We believe that interfaces should be
immutable and appropriate naming convention adopted as interfaces are
changed over time (though this is itself outside the scope of the WG).

 

4.      Ability for the user to know type of attributes ahead of time

 

5.      Input/output messages that manipulate attributes can be
validated against WSDL

 

6.      Static attributes

What are the semantics of a "static attribute"? What does it mean for a
Web Service to expose a static attribute?

 

7.      Ability to restrict access on a per attribute basis.

Not different from 1 and not an issue that WSDL should address.

8.      Ability to restrict read vs. write access

 

9.      Attributes inheritance through WSDL 1.2 interface inheritance

 

10. Metadata on attributes (creation date, type, description...)

An attribute is part of the interface of a service. What are the
semantics of a "creation date" metadata?

 

11. Bulk retrieval of several attributes in one operation

This is tantamount to specifying the base interface for all Web
services, and is in our opinion out of scope, though it definitely is in
scope for particular application frameworks like OGSI.

 

12. Attributes can be of any schema type (simple or complex)


Proposed Solution:


The attributes task force proposes the inclusion of attribute
declarations to WSDL interfaces as presented in this document. Declaring
attributes in the WSDL interface provides a uniform way of declaring
information items constituting the publicly available state of a Web
service that can be accessed or modified by Web service requestors. 

The above paragraph introduces semantics to Web Services that do not
exist in WSA. What does it mean for a Web Service to have "information
items constituting the publicly available state [...] that can be
accessed or modified..."? There is nothing in WSA to support this. We
believe that WSDL should be an interface description language of the
semantics defined in WSA.

Based on the experience gained in OGSI, we assert that providing a
syntactic convention for declaring attributes in the interface with
accessibility options is useful for tools to build systems. 

This syntactic convention is associated with a very flexible mechanism
to associate access mechanisms with the attribute declaration.

 

The proposed solution has two components:

A mechanism to define Attributes as part of an interface definition;

A mechanism to describe how Attributes and their values can be
manipulated.

Once attributes have been introduced to a WSDL interface and the
necessary bindings have been added, the way they are "manipulated"
should be application specific.


Declaring Attributes as part of an Interface


A designer uses the attribute element to specify the names and types of
attributes associated with an interface. The attributes represent
elements of publicly available state. These elements may be read or
written. The exact means by which a requestor accesses attributes is
determined by the access mechanism(s) specified in the binding.

 

<definitions>

  <interface>

    <attribute

        name="xs:NCName" 

        type="xs:QName"

        access= "read" | "write" | "read-write"? >

      <documentation />

    </attribute>*

  </interface>

</definitions>

We propose to add an additional component, named attribute, as child of
the interface element.

The properties of the Attribute Component are as follows:

*        {name} An NCName as defined by [XML Namespaces
<http://www.w3.org/TR/wsdl12/#XMLNS#XMLNS> ].

*        {target namespace} A namespace name, as defined in [XML
Namespaces <http://www.w3.org/TR/wsdl12/#XMLNS#XMLNS> ].

*        {type} A reference, by QName to a Global XML element. 

*        {access} A fixed enumeration of strings ("read" or "write" or
"read-write").

An interface could have zero or more attribute element children. Each
element defines a single attribute. Constraints on the values of name
property are the same as constraints on the operation name property.

There is no guarantee that the list of attributes provided in the
interface is the complete list of attributes available, it is only a
minimum, required list. Attribute access mechanisms are free to define
operations to access attributes not defined in the interface, for
example by providing a way to retrieve a list of attributes at runtime.

As described above, we believe that the notion of altering the interface
of a Web Service at runtime is going to cause interoperability problems.


                    Declaring Attribute Access Style in the
Binding[1][3]


<definitions>

  <binding>

    <attribute

        name="xs:QName"?

        style="xs:AnyURI" >

      <documentation />?

    </attribute>*

  </binding>

</definitions>

The set of operations or messages that allow requestors to read and/or
write elements of a service's publicly available state is specified by
the attribute element child of a binding.

The properties of the Attribute Component are as follows:

*        {name} A reference, by QName to an attribute declared in an
interface.

*        {style} A URI, which defines in the mechanism by which
attributes can be manipulated by a requestor.

If an attribute element is defined without a value for the name
attribute, it is considered to define a generic access mechanism
available for all attributes associated with the interface. It is legal
to define zero or more such generic access mechanisms.

If an attribute element is defined with a name value, then the access
mechanism applies only to the named attribute. The access mechanism
described in this manner is in addition to the set of "generic" access
mechanisms that may be associated with the binding. It is legal to
define zero or more access mechanisms for a specific attribute.

Through a combination of "generic" and named attribute bindings, all
attributes defined in the interface MUST be associated with at least one
access mechanism.

Because the set of attributes for an interface may be a superset of the
attributes defined in the interface, it is legal to include an attribute
element in the binding that refers to (by name) an attribute that does
not appear in the attributes listed in the interface. Although this is a
deviation from how bindings refer to operations in interfaces, it is
required for attributes to support the notion of "dynamic attributes" as
suggested from the OGSI work. Attributes not listed in the interface can
also be accessed through a generic access mechanism if there is some
means by which the requestor can discover the list of attributes
available at runtime.

 

A binding mechanism specifies the way a message described in WSDL is to
be transmitted via a particular network protocol (e.g., SOAP over HTTP,
HTTP, TCP/IP, Pigeons, etc.). We believe that a binding mechanism
similar to that used for an operation is enough:

<definitions>

   <binding>

      <attribute name="xs:NCName"?>

         <documentation/>?

      </attribute>*

   </binding>

</definitions>

In the case of SOAP binding, a new element will be required. 

<definitions>

   <binding>

      <attribute>

         <soap:attribute uri="uri"? />

      </attribute>

   </binding>

</definitions>

We believe that the discussions about different access mechanisms are
not relevant to WSDL. However, we provide some comments. 


1.1.1. Attribute Access Mechanisms


The access mechanism identified by the URI value of the style attribute
defines the semantic of how the attributes declared at the interface
level can be accessed. The designer of the attribute binding chooses
access mechanisms from one of possibly many different choices.

What does an "access mechanism" mean? A Web Service accepts or sends
messages. It can't provide "access mechanisms".

The creator of an access mechanism is free to use any approach he or she
chooses to define the access mechanism, be it pure English or a mix of
WSDL constructs and English, RDF, etc. Nevertheless, the description of
the access mechanism must provide enough information for the requestor
to derive a set of named operations (and their signatures) as well as
the QName of an interface containing all the operations in the access
mechanism. 

What does it mean to "for the requestor to derive a set of named
operations (and their signatures" at the binding level? Surely, the way
a tool provides programmatic support to send/received messages to/from
attributes of a Web Service should not be reflected at the interface
level.


[SNIP]


We believe that the text describing access mechanisms is not relevant to
WSDL.

 

.savas.


  _____  

[1][3] Note: this section is subject to change, reflecting continuing
discussions regarding changes to the binding element by the WSDL WG.