Sure, I'll file a bug report, I just wanted to make sure this is a
valid issue before I do that.
Jerry
On 12/13/05, Doug Kohlert <Doug.Kohlert_at_sun.com> wrote:
> Thanks Jerry,
> Would you please file a bug on this?
>
>
>
> Jerry Pisk wrote:
>
> >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
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >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
>
>