You're right, of course, I'm confusing things again. Global elements are always qualified, and the elementFormDefault and attributeFormDefault attributes apply to the local elements.
And I see now that my problem was something completely different than Marks. The example I gave where the child element unsets the namespace happened because in my WSDL file I defined the A element as being of a type TypeA that I was importing from a different namespace and I now discovered that the schema for the other namespace had elementFormDefault set to "unqualified". This is why the B element had the xmlns="" attribute, as B was a local element in the other namespace, and as such had to be unqualfied... Phew, these web service thingies can sure get complex if you ask me... ;-) Regards, Jan On 5/25/05, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > Actually, it's the opposite. If you specify > elementFormDefault="qualified", then all elements defined within the > schema by default are namespace qualified. And to override the > default, you would need to specify form="unqualified" on the specific > element. > > Note that when using RPC style, you don't have a schema for the SOAP > element structure. The only thing the schema specifies is type > information. The RPC convention sets namespaces according to these > rules: > > - the child element of the <soap:Body> is a generated element (the > method name element) which has a namespace equal to the value of the > namespace attribute in the <input> definition and a local name equal > to the value of the name attribute in the <operation> definition. > - the parameter accesssor elements (the children of the method name > element) are generated elements. These elements are always > unqualified. Their local names are equal to the value of the name > attribute on the <part> definition. > - children of the accessor elements correspond to the structure > defined in the schema that defines the accessor element type > structures. > > Anne > > On 5/25/05, Jan Delannoy <[EMAIL PROTECTED]> wrote: > > If I'm not mistaking, when the schema elementFormDefault is set to > > qualified this only means that the global element declarations (i.e. > > those that are direct children of the schema element) should be > > namespace qualified. The local declarations (defined inside other > > elements or complexTypes) default back to not qualified. So unless > > the local elements specifically have the form="qualified" attribute > > declared on them, they are not namespace qualified. I've noticed that > > Axis handles this by 'unsetting' the namespace on local elements, like > > this: > > > > <A xmlns="http://some.namespace.uri";> > > <B xmlns=""> > > ... > > </B> > > </A> > > > > I've also noticed that some tools don't like these kinds of XMLs. In > > my case I solved it by explicitly setting the form="qualfied" on my > > local declarations too. > > > > Hope this helps... > > Jan > > > > > > > > On 5/24/05, Mark Ford <[EMAIL PROTECTED]> wrote: > > > In my application, I am deserializing the incoming RPC encoded messages > > > into > > > a DOM and then validating the DOM against the schema. I'm not using any > > > generated code in this process, rather I register a custom deserializer to > > > handle complex types and produce a Document. > > > > > > My problem is that validation fails in cases where the elementFormDefault > > > for the schema is set to qualified. This requires that all child elements > > > of > > > a given element have the same namespace as their parent. The messages > > > that I > > > receive from axis generated drivers do not provide any namespace > > > information > > > for the multiRef elements. > > > > > > Here's the output from the soap monitor: > > > > > > <soapenv:Envelope > > > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > > > <soapenv:Body> > > > <test > > > soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";> > > > <datain href="#id0"/> > > > </test> > > > <multiRef id="id0" soapenc:root="0" > > > soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"; > > > xsi:type="ns1:DocumentDataIn" > > > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; > > > xmlns:ns1="http://www.active-endpoints.com/wsdl/unit_complex_return";> > > > <data1 href="#id1"/> > > > <data2 href="#id2"/> > > > </multiRef> > > > <multiRef id="id2" soapenc:root="0" > > > soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"; > > > xsi:type="xsd:float" > > > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";>123.45</multiRef> > > > <multiRef id="id1" soapenc:root="0" > > > soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"; > > > xsi:type="xsd:int" > > > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";>10</multiRef> > > > </soapenv:Body> > > > </soapenv:Envelope> > > > > > > The resulting DOM looks like this: > > > > > > <datain> > > > <data1>10</data1> > > > <data2>123.45</data2> > > > </datain> > > > > > > But it should look like this: > > > > > > <datain > > > xmlns:ns1="http://www.active-endpoints.com/wsdl/unit_complex_return";> > > > <ns1:data1>10</ns1:data1> > > > <ns1:data2>123.45</ns1:data2> > > > </datain> > > > > > > It seems to me that the inbound message is wrong since there is no way to > > > convey to the receiver that data1 and data2 are qualified. The SOAP 1.1 > > > spec > > > clearly states that the accessor elements that contain the href should not > > > be namespace qualified but it also has an example that shows a namespace > > > prefix being used in the multifRef encoding element > > > (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383520). The > > > SerializationContext in axis uses the same QName for multiRefs and it has > > > the empty namespace. It seems like there should be a way for the multiRef > > > element to have a namespace prefix. > > > > > > My workaround is to have my custom deserializer check the type of each > > > element that I'm deserializing to see if it has a form="qualified" in the > > > schema or if the schema's elementFormDefault="qualified". > > > > > > I would appreciate any suggestions or other feedback, thanks. > > > > > > > > >
