The following types are defined in WSDL, I only show the types as the
rest of the WSDL is pretty standard and works when the derived types
are not used:
<xsd:complexType name="Shape" abstract="true" />
<xsd:complexType name="Point">
<xsd:complexContent mixed="false">
<xsd:extension base="tns:Shape">
<xsd:sequence>
<xsd:element name="id" type="xsd:string"
minOccurs="0" maxOccurs="1" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
This is a message as it comes from .Net:
<?xml version="1.0" encoding="utf-8"?><soap:Envelope
xmlns:soap="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="
http://www.w3.org/2001/XMLSchema"><soap:Body><Request
xmlns="
http://ws.example.org/service/v2/types"><feature
xsi:type="Point"><id>Test</id></feature></Request></soap:Body></soap:Envelope>
The same message would use a prefix (ns0) instead of default
namespace, all elements starting with Request will be prefixed and
feature's xsi:type will be prefixed as well, ns0:Point.
Jerry
On 12/12/05, Doug Kohlert <Doug.Kohlert_at_sun.com> wrote:
> Jerry,
> Would you mind including an actual sample .NET SOAP message that shows
> this condition?
>
> thanks
>
> Jerry Pisk wrote:
>
> >Hello,
> >
> >I have been trying to use jax-rpc based web service from a .Net client
> >and I've ran into an issue regarding default namespaces. The .Net
> >framework puts its SOAP message into the default namespace, which is
> >causing derived types not to be recognized because xsi:type value that
> >specifies the actual element type is being decoded using
> >com.sun.xml.rpc.streaming.XMLReaderUtil.decodeQName() which includes
> >the following comment (and behaves as stated):
> >
> > // NOTE: Here it is assumed that we do not want to use default namespace
> > // declarations and therefore a null prefix means "no namespace" and
> > // not "default namespace"
> >
> >I think this is incorrect and that no prefix should mean the default
> >namespace. I looked up the W3C's XML Schema technical report and at
> >http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#src-qname
> >it states:
> >
> >Schema Representation Constraint: QName Interpretation
> >
> >Where the type of an attribute information item in a document involved
> >in ·validation· is identified as ·QName·, its ·actual value· is
> >composed of a [Definition:] local name and a [Definition:] namespace
> >name. Its ·actual value· is determined based on its ·normalized value·
> >and the containing element information item's [in-scope namespaces]
> >following [XML-Namespaces]:
> >The appropriate case among the following must be true:
> >
> >1 If its ·normalized value· is prefixed, then all of the following must be true:
> >1.1 There must be a namespace in the [in-scope namespaces] whose
> >[prefix] matches the prefix.
> >1.2 its ·namespace name· is the [namespace name] of that namespace.
> >1.3 Its ·local name· is the portion of its ·normalized value· after
> >the colon (':').
> >2 otherwise (its ·normalized value· is unprefixed) all of the
> >following must be true:
> >2.1 its ·local name· is its ·normalized value·.
> >2.2 The appropriate case among the following must be true:
> >2.2.1 If there is a namespace in the [in-scope namespaces] whose
> >[prefix] has no value, then its ·namespace name· is the [namespace
> >name] of that namespace.
> >2.2.2 otherwise its ·namespace name· is ·absent·.
> >In the absence of the [in-scope namespaces] property in the infoset
> >for the schema document in question, processors must reconstruct
> >equivalent information as necessary, using the [ namespace attributes]
> >of the containing element information item and its ancestors.
> >
> >To me 2.2.1 means that no prefix should be interpreted as the default
> >namespace in the node's context (a namespace whose prefix has no value
> >is the default namespace). Any thoughts? This change will make jax-rpc
> >interoperable with .Net framework's web services client code so I
> >personally do not have an option but to make the change but I would
> >like to get comments on what the proper implementation is, get it
> >implemented in jax-rpc (or jax-ws, I have not checked that code yet)
> >and solicit comments on what might be affected by this change other
> >than the xsi:type's decoding.
> >
> >Jerry Pisk
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe_at_jax-rpc.dev.java.net
> >For additional commands, e-mail: dev-help_at_jax-rpc.dev.java.net
> >
> >
> >
>
> --
> - Doug
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jax-rpc.dev.java.net
> For additional commands, e-mail: dev-help_at_jax-rpc.dev.java.net
>
>