W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2007

Re: a few Woden problems

From: Jacek Kopecky <jacek.kopecky@deri.org>
Date: Thu, 03 May 2007 00:07:24 +0200
To: Arthur Ryman <ryman@ca.ibm.com>
Cc: John Kaputin <KAPUTIN@uk.ibm.com>, WS-Description WG <www-ws-desc@w3.org>
Message-Id: <1178143644.16926.103.camel@localhost>

Arthur, John,

I think I understand, but I also think that such approach is somewhat
short-sighted. The thing is - the HTTP properties are not changed by
being reused (in particular, the names and the extension attributes stay
the same) so I expect that they should be accessible as HTTP properties,
whether or not they are also accessible as SOAP properties as well.

With the current Woden design, I can have some extension properties (in
this case HTTP properties) and extend Woden to handle them, but somebody
else can create other extensions (like another binding, in this case
SOAP) and extend Woden and invalidate my old way of getting to my
properties that haven't changed at all. None of the extensions involved
is mustUnderstand, therefore they shouldn't have such effects on each
other.

I guess the question is whether the meaning of a property like {http
location} can change with the presence of other non-mustUnderstand
extension properties or values. The change of the meaning would give a
reason for an API change.

Wondering what John thinks,
Jacek

On Wed, 2007-05-02 at 15:56 -0400, Arthur Ryman wrote:
> 
> Jacek, 
> 
> I believe the rationale is that the binding is SOAP but it just
> happens to reuse some properties defined in the HTTP binding. I am
> including John who can give his opinion. 
> 
> Arthur Ryman, PhD, AoT, DE
> Process and Portfolio Management, Rational Division
> 
> phone: +1-905-413-3077, TL 969-3077
> assistant: +1-905-413-3831 (T/L: 318-8867)
> fax: +1-905-413-4920, TL 969-4920
> mobile: +1-416-939-5063, text: 4169395063@fido.ca 
> 
> 
> Jacek Kopecky
> <jacek.kopecky@deri.org> 
> Sent by:
> www-ws-desc-request@w3.org 
> 
> 05/02/2007 02:42 PM 
> 
> 
>                To
> Arthur
> Ryman/Toronto/IBM@IBMCA 
>                cc
> WS-Description WG
> <www-ws-desc@w3.org> 
>           Subject
> a few Woden
> problems
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hi Arthur, 
> I uncovered a few more Woden problems. If I'm emailing you improperly,
> please let me know who to address instead.*
> 
> 1) (design) the SOAP binding reuses HTTP properties. In Woden, the
> reused properties are returned when looking at the SOAP extensions 
> (for instance SOAPBindingExtensions.isHttpCookies(), and all similar
> occurrences). I believe this is counterintuitive - when I'm looking
> for
> the value of the {http cookies} property on a binding, it's defined by
> a
> WHTTP extension attribute and it should be available under that
> namespace.
> 
> Why do I care? The RDF binding maps {http cookies} into the same thing
> whether it is on an HTTP binding or on a SOAP binding, and I must
> check
> two different extensions to get the value of this property.
> 
> SOAPBindingExtensions.isHttpCookies(), if it's there at all, should
> IMHO
> be syntactic sugar for HTTPBindingExtensions.isHttpCookies() on the
> same
> binding, but as it is, I don't even get HTTPBindingExtensions on a
> SOAP
> binding. The type of a binding should not dictate the namespaces of
> allowed extensions, or under what namespaces one can find some
> properties. I don't think the spec intends that.
> 
> 
> 2) (may get obsoleted if you agree on the point above)
> SOAPBindingOperationExtensions does not have
> isHttpLocationIgnoreUncited
> even though the SOAP binding seems to import this property (cf. first
> bullet in section 5) Currently, Woden does not give me the value of
> this
> property on SOAP bindings.
> 
> 
> 3) InterfaceImpl.getAllInterfaceOperations and getAllInterfaceFaults
> are
> not quite recursive, they only go one level of interface extension
> deep.
> This manifests in the flickr test-suite WSDL file when trying to
> access
> the InterfaceOperation of the BindingOperation for
> "flickr.groups.pools.add" - the method getInterfaceOperation() returns
> null because the actual operation is too deep in the hierarchy of
> extended interfaces.
> 
> Fix: in both InterfaceImpl.getDerivedInterface*, change getInterface*
> to
> getAllInterface* - this can get into an infinite loop if a circular
> interface extension is not detected as an error first.
> 
> 
> For the purpose of finishing the RDF mapping, I have a work-around for
> 1), I fixed 3) in my copy of Woden, but I can't easily fix 2).
> 
> Best regards,
> Jacek
> 
> *P.S: I don't want to have to subscribe for a mailing list or register
> in a bug reporting system, though, to be able to submit these
> questions.
> 
> 
> 
> 
Received on Wednesday, 2 May 2007 22:07:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:47 GMT