Re: Attributes, yes. Set/Get operations, no.

To your points:

>Point 1)  I don't see much advantage to defining get/set operation syntax;

The point is for interoperability.  Simply defining the attributes provides
little value above simple documentation.  If a requestor sees an attribute
but doesn't know how to get/set it, it is not much use the attribute being
part of the serviceDescription unless it is clear to the requestor how it
can be viewed/manipulated.

>get/set aren't a very powerful language for describing what a service
does.

Get/Set doesn't describe what a service does in its entirety, it just
standardizes a base pair of operations that allow very simple manipulation
of state values.

>For example,  If I define a JobQueue as an attribute for a service, I can
>define operations like JoinQueue, PurgeHead, PurgeQueue, PurgeByOwner etc
>etc. Set and Get aren't always desirable. Obviously, the binding is not
the
>right place to define these operations, so I don't see it as the place for
>get/set either, if those were the operations that were needed.

Why are you defining the JobQueue as an attribute in the first place?

>So, my vote amongst a) - d) is e) - None of the above. Let's keep it
simple
>and just define the attributes, leaving the definition of their
>manipulation to the operations defined by an interface which includes the
>attributes. What's the point of the attributes?  They provide a way for
>describing the semantics of the service. Operations on a stateful service
>leave some effect on the state at their completion, and the attributes
help
>describe that effect.   In OGSI, they are also used for introspection; Get
>is a major use. However, I think, this is a requirement that needs to be
>treated as a special case.

It strikes me very odd that there is any use for a concept of attributes as
a
"hint" or additional meta data about the service without a clear indication
to
the requestor how to get/set the values of the attribute.  I don't see how
just an attribute helps describe the semantics of a service at all. Further
I
find it very odd that a base "get" case would be regarded as a special
case.

>Point 2)

>What are the semantics of the proposed Get and Set?  There are two ways to
>go: the OGSI way, where the value of a Set may not show up in the value
>retrieved by a subsequent Get for some time  after the Set completes. Or
>there's the more instinctive way where the Set is immediately reflected in
>the real attribute state and a Get can get is right away. (Who can tell me
>what happens in CORBA IDL?)   I think the way out of this awkwardness is
to
>let the interface define the semantics.
This is a good point, however the interface defines some of the semantics
there needs to be some way that the implementation can determine the timing
of when the change is visible.

>Point 3)

>It is a requirement, I think, to define the way the semantics of an
>interface may change/be preserved when an interface is extended. Suppose
>interface A is extended by B; can B modify the semantics of the attributes
>defined by A?
What exactly do you mean by "the semantics of the attributes"?  I am not
sure
what this means, and therefore I am not sure what this means with regards
to
interface extension.  Why would it be any different than operations?

sgg


++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
++++++++



                                                                                                                                              
                      "Tim Banks"                                                                                                             
                      <tim_banks@uk.ibm.com>          To:       <public-ws-desc-state@w3.org>                                                 
                      Sent by:                        cc:                                                                                     
                      public-ws-desc-state-req        Subject:  Attributes, yes. Set/Get operations, no.                                      
                      uest@w3.org                                                                                                             
                                                                                                                                              
                                                                                                                                              
                      07/21/2003 07:52 AM                                                                                                     
                                                                                                                                              
                                                                                                                                              





On 19/07/2003 18:20 Steve Graham wrote:

> So, a requestor examines a WSDL interface and determines that there is an
> attribute element in it.  How does this observation inform the requestor
> what operations are now legal to send and how can the requestor determine
> what the proper input and output messages could look like?
 ...
> We need to discuss more details regarding the "operational" model as
> suggested in [1] could look like CORBA IDL's treatment of attributes.
> Therein, there is an "implicit" operation (or get/set pair of operations)
> defined for each attribute defined in the interface.
> I see several possible approaches:
> a) CORBA IDL-like convention
> b) similar to a) but single operation, no strong typing
> c) JavaBeans pattern
> d) a "base" Web services interface that defines the attribute
> operations.


Three points to make here:

Point 1)  I don't see much advantage to defining get/set operation syntax;
get/set aren't a very powerful language for describing what a service does.
Of course, operations which access attributes shouldn't be restricted to
get/set, so it's worth considering what would be lost if we just defined
attributes and left out the get and set operations.

For example,  If I define a JobQueue as an attribute for a service, I can
define operations like JoinQueue, PurgeHead, PurgeQueue, PurgeByOwner etc
etc. Set and Get aren't always desirable. Obviously, the binding is not the
right place to define these operations, so I don't see it as the place for
get/set either, if those were the operations that were needed.

So, my vote amongst a) - d) is e) - None of the above. Let's keep it simple
and just define the attributes, leaving the definition of their
manipulation to the operations defined by an interface which includes the
attributes.  What's the point of the attributes?  They provide a way for
describing the semantics of the service. Operations on a stateful service
leave some effect on the state at their completion, and the attributes help
describe that effect.   In OGSI, they are also used for introspection; Get
is a major use. However, I think, this is a requirement that needs to be
treated as a special case.

Point 2)

What are the semantics of the proposed Get and Set?  There are two ways to
go: the OGSI way, where the value of a Set may not show up in the value
retrieved by a subsequent Get for some time  after the Set completes. Or
there's the more instinctive way where the Set is immediately reflected in
the real attribute state and a Get can get is right away. (Who can tell me
what happens in CORBA IDL?)   I think the way out of this awkwardness is to
let the interface define the semantics.

Point 3)

It is a requirement, I think, to define the way the semantics of an
interface may change/be preserved when an interface is extended. Suppose
interface A is extended by B; can B modify the semantics of the attributes
defined by A?


Regards, Tim Banks
IBM TP Architecture & Technology. Hursley, UK.
Phone: External +44 1962 815639, Internal 245639

Received on Monday, 21 July 2003 10:53:03 UTC