Skip Menu |

This queue is for tickets about the XML-Compile-SOAP CPAN distribution.

Report information
The Basics
Id: 107757
Status: resolved
Priority: 0/
Queue: XML-Compile-SOAP

People
Owner: Nobody in particular
Requestors: hausauer [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: ref'd elements are incorrectly qualified
Date: Tue, 13 Oct 2015 13:45:17 -0700
To: bug-XML-Compile-SOAP [...] rt.cpan.org
From: Derek Hausauer <hausauer [...] gmail.com>
I’m using XML-Compile-SOAP-3.12. It looks like ref elements are being fully qualified when they shouldn’t be. Given the following WSDL: <wsdl:definitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://somenamespace" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:ns1="http://schemas.xmlsoap.org/soap/http" name="SomeService" targetNamespace="http://somenamespace"> <wsdl:types> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xmime="http://www.w3.org/2005/05/xmlmime" xmlns:tns="http://somenamespace" elementFormDefault="unqualified" targetNamespace="http://somenamespace" version="1.0"> <xs:import namespace="http://www.w3.org/2005/05/xmlmime"/> <xs:element name="SomeParam" type="tns:SomeParam"/> <xs:element name="SomeRefType" type="tns:SomeRefType"/> <xs:element name="someMethod" type="tns:someMethod"/> <xs:element name="someResponse" type="tns:someResponse"/> <xs:complexType name="SomeParam"> <xs:sequence> <xs:element minOccurs="0" ref="tns:SomeRefType"/> </xs:sequence> </xs:complexType> <xs:complexType name="SomeRefType"> <xs:sequence> <xs:element name="SomeValue" type="xs:int"/> </xs:sequence> </xs:complexType> <xs:complexType name="genericResponse"> <xs:sequence> <xs:element name="returnValue" type="xs:int"/> </xs:sequence> </xs:complexType> <xs:complexType name="someMethod"> <xs:sequence> <xs:element minOccurs="0" name="arg0" type="tns:SomeParam"/> </xs:sequence> </xs:complexType> <xs:complexType name="someMethodResponse"> <xs:sequence> <xs:element minOccurs="0" name="return" type="tns:genericResponse"/> </xs:sequence> </xs:complexType> </xs:schema> </wsdl:types> <wsdl:message name="someMethodResponse"> <wsdl:part element="tns:someMethodResponse" name="parameters"></wsdl:part> </wsdl:message> <wsdl:message name="someMethod"> <wsdl:part element="tns:someMethod" name="parameters"></wsdl:part> </wsdl:message> <wsdl:portType name="SomeService"> <wsdl:operation name="someMethod"> <wsdl:input message="tns:someMethod" name="someMethod"></wsdl:input> <wsdl:output message="tns:someMethodResponse" name="someMethodResponse"></wsdl:output> </wsdl:operation> </wsdl:portType> <wsdl:binding name="SomeServiceSoapBinding" type="tns:SomeService"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="someMethod"> <soap:operation soapAction="" style="document"/> <wsdl:input name="someMethod"> <soap:body use="literal"/> </wsdl:input> <wsdl:output name="someMethodResponse"> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="SomeService"> <wsdl:port binding="tns:SomeServiceSoapBinding" name="SomeServicePort"> <soap:address location="http://localhost/SomeService"/> </wsdl:port> </wsdl:service> </wsdl:definitions> In calling someMethod, the following request is generated: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <tns:someMethod xmlns:tns="http://somenamespace"> <arg0> <tns:SomeParam> <SomeValue>1</SomeValue> </tns:SomeParam> </arg0> </tns:someMethod> </SOAP-ENV:Body> </SOAP-ENV:Envelope> <tns:SomeParam> should not have been qualified; it should appear as just <SomeParam>. I suspect this is because the reference is followed to a top-level element for which nsContext() in XML::Compile::Translate forces to a qualified tag. I’m not sure how to modify the code to prevent this from happening. Because the request has "<tns:SomeParam>" instead of just "<SomeParam>", our SOAP web server (Apache CXF) throws the following exception: Unmarshalling Error: unexpected element (uri:"http://somenamespace", local:"SomeParam"). Expected elements are &lt;{}SomeParam> Other frameworks (ie. JAX-WS) do not include the tns prefix on SomeParam and work fine. — Derek
Subject: Re: [rt.cpan.org #107757] AutoReply: ref'd elements are incorrectly qualified
Date: Tue, 13 Oct 2015 15:20:43 -0700
To: bug-XML-Compile-SOAP [...] rt.cpan.org
From: Derek Hausauer <hausauer [...] gmail.com>
Note: I was able to get the XML::Compile::XOP generated code to work adding elementFormDefault="qualified" to my <xs:schema> declaration in the WSDL: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xmime="http://www.w3.org/2005/05/xmlmime" xmlns:tns="http://somenamespace"elementFormDefault="qualified" targetNamespace="http://somenamespace" version="1.0"> Since this was an Apache CXF project, I forced the addition of elementFormDefault by adding a package-info.java file to the project and adding the following @XmlSchema annotation to the package declaration: @javax.xml.bind.annotation.XmlSchema(namespace = "http://somenamespace", elementFormDefault= XmlNsForm.QUALIFIED) package somepackage; import javax.xml.bind.annotation.XmlNsForm; Show quoted text
> On Oct 13, 2015, at 1:45 PM, Bugs in XML-Compile-SOAP via RT <bug-XML-Compile-SOAP@rt.cpan.org> wrote: > > > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "ref'd elements are incorrectly qualified", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [rt.cpan.org #107757]. Your ticket is accessible > on the web at: > > https://rt.cpan.org/Ticket/Display.html?id=107757 > > Please include the string: > > [rt.cpan.org #107757] > > in the subject line of all future correspondence about this issue. To do so, > you may reply to this message. > > Thank you, > bug-XML-Compile-SOAP@rt.cpan.org > > ------------------------------------------------------------------------- > I’m using XML-Compile-SOAP-3.12. It looks like ref elements are being fully qualified when they shouldn’t be. > > Given the following WSDL: > > <wsdl:definitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://somenamespace" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:ns1="http://schemas.xmlsoap.org/soap/http" name="SomeService" targetNamespace="http://somenamespace"> > <wsdl:types> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xmime="http://www.w3.org/2005/05/xmlmime" xmlns:tns="http://somenamespace" elementFormDefault="unqualified" targetNamespace="http://somenamespace" version="1.0"> > <xs:import namespace="http://www.w3.org/2005/05/xmlmime"/> > <xs:element name="SomeParam" type="tns:SomeParam"/> > <xs:element name="SomeRefType" type="tns:SomeRefType"/> > <xs:element name="someMethod" type="tns:someMethod"/> > <xs:element name="someResponse" type="tns:someResponse"/> > <xs:complexType name="SomeParam"> > <xs:sequence> > <xs:element minOccurs="0" ref="tns:SomeRefType"/> > </xs:sequence> > </xs:complexType> > <xs:complexType name="SomeRefType"> > <xs:sequence> > <xs:element name="SomeValue" type="xs:int"/> > </xs:sequence> > </xs:complexType> > <xs:complexType name="genericResponse"> > <xs:sequence> > <xs:element name="returnValue" type="xs:int"/> > </xs:sequence> > </xs:complexType> > <xs:complexType name="someMethod"> > <xs:sequence> > <xs:element minOccurs="0" name="arg0" type="tns:SomeParam"/> > </xs:sequence> > </xs:complexType> > <xs:complexType name="someMethodResponse"> > <xs:sequence> > <xs:element minOccurs="0" name="return" type="tns:genericResponse"/> > </xs:sequence> > </xs:complexType> > </xs:schema> > </wsdl:types> > <wsdl:message name="someMethodResponse"> > <wsdl:part element="tns:someMethodResponse" name="parameters"></wsdl:part> > </wsdl:message> > <wsdl:message name="someMethod"> > <wsdl:part element="tns:someMethod" name="parameters"></wsdl:part> > </wsdl:message> > <wsdl:portType name="SomeService"> > <wsdl:operation name="someMethod"> > <wsdl:input message="tns:someMethod" name="someMethod"></wsdl:input> > <wsdl:output message="tns:someMethodResponse" name="someMethodResponse"></wsdl:output> > </wsdl:operation> > </wsdl:portType> > <wsdl:binding name="SomeServiceSoapBinding" type="tns:SomeService"> > <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> > <wsdl:operation name="someMethod"> > <soap:operation soapAction="" style="document"/> > <wsdl:input name="someMethod"> > <soap:body use="literal"/> > </wsdl:input> > <wsdl:output name="someMethodResponse"> > <soap:body use="literal"/> > </wsdl:output> > </wsdl:operation> > </wsdl:binding> > <wsdl:service name="SomeService"> > <wsdl:port binding="tns:SomeServiceSoapBinding" name="SomeServicePort"> > <soap:address location="http://localhost/SomeService"/> > </wsdl:port> > </wsdl:service> > </wsdl:definitions> > > In calling someMethod, the following request is generated: > > <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> > <SOAP-ENV:Body> > <tns:someMethod xmlns:tns="http://somenamespace"> > <arg0> > <tns:SomeParam> > <SomeValue>1</SomeValue> > </tns:SomeParam> > </arg0> > </tns:someMethod> > </SOAP-ENV:Body> > </SOAP-ENV:Envelope> > > <tns:SomeParam> should not have been qualified; it should appear as just <SomeParam>. I suspect this is because the reference is followed to a top-level element for which nsContext() in XML::Compile::Translate forces to a qualified tag. I’m not sure how to modify the code to prevent this from happening. > > Because the request has "<tns:SomeParam>" instead of just "<SomeParam>", our SOAP web server (Apache CXF) throws the following exception: > > Unmarshalling Error: unexpected element (uri:"http://somenamespace", local:"SomeParam"). Expected elements are &lt;{}SomeParam> > > Other frameworks (ie. JAX-WS) do not include the tns prefix on SomeParam and work fine. > > — > Derek
Subject: Re: [rt.cpan.org #107757] ref'd elements are incorrectly qualified
Date: Wed, 14 Oct 2015 00:21:05 +0200
To: Derek Hausauer via RT <bug-XML-Compile-SOAP [...] rt.cpan.org>
From: Mark Overmeer <mark [...] overmeer.net>
* Derek Hausauer via RT (bug-XML-Compile-SOAP@rt.cpan.org) [151013 20:45]: Show quoted text
> Tue Oct 13 16:45:44 2015: Request 107757 was acted upon. > Transaction: Ticket created by hausauer@gmail.com > Queue: XML-Compile-SOAP > Subject: ref'd elements are incorrectly qualified > > I’m using XML-Compile-SOAP-3.12. It looks like ref elements are being fully qualified when they shouldn’t be. > > Given the following WSDL: > > <wsdl:definitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://somenamespace" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:ns1="http://schemas.xmlsoap.org/soap/http" name="SomeService" targetNamespace="http://somenamespace"> > > <tns:SomeParam> should not have been qualified; it should appear as > just <SomeParam>. I suspect this is because the reference is followed > to a top-level element for which nsContext() in XML::Compile::Translate > forces to a qualified tag. I’m not sure how to modify the code to > prevent this from happening.
There has be a change in this respect in 1.44, after I had to reread the specification. The spec is very hard to understand, but the guy who complained was right. It solved communication with his server. Schema's with elementFormDefault="unqualified" are rare, which may explain for bug unnoticed. The basic rule is: "top-levels are always qualified" Maybe you can find the rule which makes an exception for refs in http://www.w3.org/TR/xmlschema11-1/#ref.elt.global It depends on the spec whether I have to implement an option for you to escape from the specs, or fix my code. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions drs Mark A.C.J. Overmeer MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
I think this got resolved a year ago, so close it for now.