You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by "Mark D. Hansen" <m....@verizon.net> on 2004/07/30 23:46:43 UTC
doc/lit ==> Call doesn't send xsi:type attributes ??
I'm trying to use org.apache.axis.client.Call to invoke a doc/lit service, and I would like it to send the xsi:type attributes of the parameters (I'm using WRAPPED style). Using TCPMonitor, I notice that Axis doesn't send the xsi:type attributes. So, I dug into the org.apache.axis.client.Call code a little and noticed that this is by design. The Call code turns off xsi:type attributes in the serialization context when the service is doc/lit. Is this a requirement of the WSDL specification or just the Axis default behavior?
Thanks,
Mark
RE: doc/lit ==> Call doesn't send xsi:type attributes ??
Posted by Anne Thomas Manes <an...@manes.net>.
Robert,
I agree with you that the rule stipulates only that a SOAP node MUST NOT
mandate use of the xsi:type attribute. I also agree that a SOAP node MUST be
able to process messages containing the xsi:type attribute.
The text above the rule, though, indicates the best practice: you SHOULD NOT
use xsi:type in a literal message unless (a) the schema does not specify the
type (e.g., type="anyType") or (b) you need to override the type. Adding
type information that duplicates the original schema definition just adds
unnecessary bulk to the message and increases processing.
It is certainly valid to override the type in an XML document instance --
but if you do so, the message does not conforming to the expected schema.
Results are unpredictable.
Anne
-----Original Message-----
From: Robert van Engelen [mailto:engelen@cs.fsu.edu]
Sent: Tuesday, August 03, 2004 9:30 PM
To: axis-user@ws.apache.org
Subject: Re: doc/lit ==> Call doesn't send xsi:type attributes ??
Dear Anne,
IMO your quote is correct, but your conclusion is not. BP1.0a states
that receivers must not require the use of xsi:type. But this does not
mean that senders are restricted in their inclusion of xsi:type
attributes. In fact, Schema Part 1: Structures, Section 2.6.1 states
that "An element information item in an instance may, however,
explicitly assert its type using the attribute xsi:type.". This does
not mention any specific cases.
Thus, SOAP toolkits that reject messages that include xsi:type
attributes are not compliant with BP1.0a.
Cheers,
- Robert
On Sunday, August 1, 2004, at 02:01 PM, Anne Thomas Manes wrote:
> When using doc/literal, you are supposed to send messages that conform
> to
> the schema definition (that's what "literal" means). Therefore you
> should
> not send type information in the message unless you need to override
> the
> schema or when no schema exists.
>
> Use of xsi:type is specified in the WS-I Basic Profile, as follows:
>
> 4.1.15 Use of xsi:type Attributes
> In many cases, senders and receivers will share some form of type
> information related to the messages being exchanged. The xsi:type
> attribute
> is only needed where no such schema exists, that is where both sides
> are
> assuming that all exchanged items are "xsd:anyType".
>
> R1017 A RECEIVER MUST NOT mandate the use of the xsi:type attribute in
> messages except as required in order to indicate a derived type (see
> XML
> Schema Part 1: Structures, Section 2.6.1).
>
> Anne
>
> -----Original Message-----
> From: Mark D. Hansen [mailto:m.hansen23@verizon.net]
> Sent: Friday, July 30, 2004 5:47 PM
> To: AXIS Users (E-mail)
> Subject: doc/lit ==> Call doesn't send xsi:type attributes ??
>
> I'm trying to use org.apache.axis.client.Call to invoke a doc/lit
> service,
> and I would like it to send the xsi:type attributes of the parameters
> (I'm
> using WRAPPED style). Using TCPMonitor, I notice that Axis doesn't
> send the
> xsi:type attributes. So, I dug into the org.apache.axis.client.Call
> code a
> little and noticed that this is by design. The Call code turns off
> xsi:type
> attributes in the serialization context when the service is doc/lit.
> Is
> this a requirement of the WSDL specification or just the Axis default
> behavior?
>
> Thanks,
>
> Mark
>
Re: doc/lit ==> Call doesn't send xsi:type attributes ??
Posted by Robert van Engelen <en...@cs.fsu.edu>.
Dear Anne,
IMO your quote is correct, but your conclusion is not. BP1.0a states
that receivers must not require the use of xsi:type. But this does not
mean that senders are restricted in their inclusion of xsi:type
attributes. In fact, Schema Part 1: Structures, Section 2.6.1 states
that "An element information item in an instance may, however,
explicitly assert its type using the attribute xsi:type.". This does
not mention any specific cases.
Thus, SOAP toolkits that reject messages that include xsi:type
attributes are not compliant with BP1.0a.
Cheers,
- Robert
On Sunday, August 1, 2004, at 02:01 PM, Anne Thomas Manes wrote:
> When using doc/literal, you are supposed to send messages that conform
> to
> the schema definition (that's what "literal" means). Therefore you
> should
> not send type information in the message unless you need to override
> the
> schema or when no schema exists.
>
> Use of xsi:type is specified in the WS-I Basic Profile, as follows:
>
> 4.1.15 Use of xsi:type Attributes
> In many cases, senders and receivers will share some form of type
> information related to the messages being exchanged. The xsi:type
> attribute
> is only needed where no such schema exists, that is where both sides
> are
> assuming that all exchanged items are "xsd:anyType".
>
> R1017 A RECEIVER MUST NOT mandate the use of the xsi:type attribute in
> messages except as required in order to indicate a derived type (see
> XML
> Schema Part 1: Structures, Section 2.6.1).
>
> Anne
>
> -----Original Message-----
> From: Mark D. Hansen [mailto:m.hansen23@verizon.net]
> Sent: Friday, July 30, 2004 5:47 PM
> To: AXIS Users (E-mail)
> Subject: doc/lit ==> Call doesn't send xsi:type attributes ??
>
> I'm trying to use org.apache.axis.client.Call to invoke a doc/lit
> service,
> and I would like it to send the xsi:type attributes of the parameters
> (I'm
> using WRAPPED style). Using TCPMonitor, I notice that Axis doesn't
> send the
> xsi:type attributes. So, I dug into the org.apache.axis.client.Call
> code a
> little and noticed that this is by design. The Call code turns off
> xsi:type
> attributes in the serialization context when the service is doc/lit.
> Is
> this a requirement of the WSDL specification or just the Axis default
> behavior?
>
> Thanks,
>
> Mark
>
RE: doc/lit ==> Call doesn't send xsi:type attributes ??
Posted by Anne Thomas Manes <an...@manes.net>.
When using doc/literal, you are supposed to send messages that conform to
the schema definition (that's what "literal" means). Therefore you should
not send type information in the message unless you need to override the
schema or when no schema exists.
Use of xsi:type is specified in the WS-I Basic Profile, as follows:
4.1.15 Use of xsi:type Attributes
In many cases, senders and receivers will share some form of type
information related to the messages being exchanged. The xsi:type attribute
is only needed where no such schema exists, that is where both sides are
assuming that all exchanged items are "xsd:anyType".
R1017 A RECEIVER MUST NOT mandate the use of the xsi:type attribute in
messages except as required in order to indicate a derived type (see XML
Schema Part 1: Structures, Section 2.6.1).
Anne
-----Original Message-----
From: Mark D. Hansen [mailto:m.hansen23@verizon.net]
Sent: Friday, July 30, 2004 5:47 PM
To: AXIS Users (E-mail)
Subject: doc/lit ==> Call doesn't send xsi:type attributes ??
I'm trying to use org.apache.axis.client.Call to invoke a doc/lit service,
and I would like it to send the xsi:type attributes of the parameters (I'm
using WRAPPED style). Using TCPMonitor, I notice that Axis doesn't send the
xsi:type attributes. So, I dug into the org.apache.axis.client.Call code a
little and noticed that this is by design. The Call code turns off xsi:type
attributes in the serialization context when the service is doc/lit. Is
this a requirement of the WSDL specification or just the Axis default
behavior?
Thanks,
Mark