axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <sanj...@watson.ibm.com>
Subject Re: array test
Date Tue, 04 Dec 2001 16:28:02 GMT
Sam writes:
> (2) The order of checking isn't consistent.  It appears that the xsi:type
> on the argument is looked at first, then the registry is looked into, then
> the xsi:type on referenced elements.

If (2) isn't fixed to always use the value of xsi:type first and then
look elsewhere then I believe the impl is basically incorrect. If I have
    <paramx xsi:type="foo:bar">value</paramx>
and then decide to write it out equivalently as:
    <paramx href="#id0"/>

    ...

    <multiref id="id0" xsi:type="foo:bar">value</paramx>
then my results could be different because axis chose to determine
a type for paramx prematurely. [Remember that xsi:type allows a
subtype value to be sent instead of the actual type.]

IMO the rule should be:
    - use xsi:type if indicated (directly or via href/id)
    - use an out of band schema type declaration
    - use some mapping based on the param name (the hack that's
      in Apache SOAP too)

> In fact, I'm not entirely comfortable with the suggestion that #2 be fixed
> in a way that the xsi:type always wins, particularly in this scenario.
> Suppose I call a service and declare that I expect an array of Foo back,
> and what actually is received is an array of ints.  Should Axis provide
> what it received, even if it did not match what was specified?  This would
> mean that every call to axis clients would have to have code which checked
> the results.  Or should this check be factored into Axis itself and a
fault
> be generated.

I think at a deserialization level axis should return whatever it finds.
A later validation or method signature check can fail because the given
value isn't of the expected type.

Sanjiva.



Mime
View raw message