Re: Something else to consider

Savas Parastatidis wrote:

> It seems to me that we are defining a set of attributes and a well 
> defined way to query/modify them without assuming the existence of 
> operations in WSDL, right? As a result, our goal is then to specify 
> well-defined messages that would instead express the same information 
> as if the operation(s) were to exist in WSDL. Not specifying the 
> message content would be unacceptable as it is an interoperability 
> problem.
>
>  
>
> It is vitally important to define the messages exchanged for 
> getting/setting the value of an attribute. Totally agree. If you see 
> Sanjiva's proposal in the main WSDL mailing list, you'll see that he 
> proposed an elegant way to remove the <message> element from WSDL. Instead, the structure of a message is defined as 
> a complex type. The proposed syntax for a WSDL attribute is based on 
> that proposal, with the exception of @headers (I owe a reply to Jim 
> about this).
>
Savas,

I am well aware of the discussions and Oracle is very interested in this 
particular topic.

Although your suggestion is based on the message removal proposal, I 
would like clarification on how one would use the combined syntax as 
some aspects are not clear to me. For example, Sanjiva suggests either a 
complexType of element to be the body and proposes some short cuts. I am 
not sure what your assumptions are when arbitrary complexTypes are the 
body of the gret message and how it relates to the specific attribute at 
hand. See below.

>  
>
>
> I had the same question as William with respect to this syntax. If I 
> understood correctly, this approach favors defining get/setXX messages 
> per attribute basis. Unless there is a well defined message where 
> multiple attribute names can be referenced, it is not clear to me how 
> a general query can be expressed. This favors using an operation 
> unless we were to extend the attribute definitions to encapsulate both 
> attributes and query messages that can be expressed, something along 
> the lines of
>
>  
>
> As both Sanjiva and Jim suggested, it is not for the WSDL 
> specification to define operations for querying attributes. That's 
> what the OGSI specification should do if it is deemed necessary.
>

That is one particular view. I have not made our mind one way or the 
other wrt where the responsibility of WSDL stops and some other 
specification begins.  All I was pointing is that we have the 
requirement and it is not satisfied. Whether we consider that the 
requirement is no longer relevant is a separate discussion. Lets stick 
with the current problem for now.

>  
>
>
>
> -- How is the complexType in the body of get/set element used? For 
> example, I would have expected the get message not to specify anything 
> as it is obvious from the structure that there is an attribute that it 
> is related to. Similarly, what are the body/element defns?
> I would not expect anything in the body of a message that corresponds 
> to this definition as it is clear from the defn which attribute that 
> the get message is for.
>
> -- The same question goes for the setter. Can a set message contain 
> information other than the value of the attribute? Again the 
> body/element defns appear to allow more than the traditional use of a 
> setter would allow. I would like to understand better.
>

>
>
>  
>
>  
>
> I would encourage you to read Sanjiva's proposal...
>
> http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0025.html
>
I have read Sanjiva's proposal ;-) . I am afraid my questions are 
specific to yours. Let me retry:

- get. If I have a foo attribute, the message does not have to indicate 
more than an attribute's name, and somehow the "get" keyword (or some 
binding specific keyword...).
- set. If I have an attribute, you would only require a value which 
conforms to the specific attribute's type as part of the message, and 
the "set" keyword.

You seem to have collapsed the input and output unlike as the message 
removal proposal. There are (3) three aspects to the message content, 
the intended keyword, the attribute's name and additional data, as the 
setters value or the return value of the get...

When I have your defn as stated below :

<attribute name="ncname">
    <get [(body="qname") | (element="qname")]>
        [<xsd:complexType> ... </xsd:complexType>]
    </get>
    <set [(body="qname") | (element="qname")] 
        [<xsd:complexType> ... </xsd:complexType>]
    </set>
</attribute >


Sanjiva's proposal clearly defines the inputs/outputs of an operation. 
Here, we don't know what the message content is and what the client and 
the service will assume. 

- Does the content of the get element indicate the intended  return 
value (type) of  the attribute (body/element/complexType)? The input is 
not indicated, so what is it based on the three aspects that are listed 
above?

- Does the content of the set element indicate the intended value (type) 
of the attribute (body/element/complexType) that is sent by the client 
to the service? The output is not indicated, so are you assuming that it 
is a one way message or can we assume a fault?

- However, if you are allowing the get element to have both a 
complexType defn and an element reference, it is not clear to me which 
 specifies the attribute, the type or the element? Therefore, I conclude 
that perhaps this intends the specification to be either a 
body/element/complexType, but not more than one above choices. Am I 
right? (*)

It looks to me that this is loosly coupled. Consider the following:

<complexType name="fooType">
....
</complexType>

<complexType name="barType">
...
</complexType>

The proposal allows the following:

<attribute name="foo">
    <get body="x:fooType"/>
    <set body="x:barType"/>
</attribute>

It seems to me that this is not correct, unless again I am missing 
something from your proposal. I am assuming that the intention is that 
the type of the attribute that we are getting is x:fooType, but the 
attribute's type is x:barType for the setter (with my interpreted 
semantics (*)). This seems wrong to me. There is only one attribute 
(hence one type) and the loose coupling allows unintended ambiguity.

I would then wonder, why we don't have the following:

<attribute name="foo" (body="x:fooType" |element="x:foo")>

or a complexType

</attribute>

instead.


>  
>
>  
>
> -- If the WSDL contains get/set operations, how would be distinguish 
> them based on the message content alone?
>
>  
>
> That will be binding-specific.
>
It seems to me that you are suggesting that the messages are not well 
defined. We need to specify for SOAP/HTTP binding rules. The message on 
the wire should not be ambiguous for the receiver to decipher it. This 
means both sides of the conversation, the message sent from the client 
and the message sent back from the service. They need to incorporate the 
get/set keywords(or some naming convention), the name of the attribute, 
and the content. If they are not part of the message, what are you 
envisioning them to be?

>  
>
> .savas.
>

Thanks.

--umit

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com