Re: Avoiding xmlns=" " in each element within the doc\literal SOAP message

[Anne Thomas Manes <an...@manes.net>]

Tony,

There's nothing wrong with this XML instance:

<soapenv:Body>
   <echoreturn xmlns="blah1">
    <ns1:vard xmlns:ns1="blah2">
     <ns1:vari>0</ns1:vari>
    </ns1:vard>
    <ns2:vard xmlns:ns2="blah2">
     <ns2:vari>0</ns2:vari>
    </ns2:vard>
    <ns3:vard xmlns:ns3="blah2">
     <ns3:vari>0</ns3:vari>
    </ns3:vard>
   </echoreturn>
  </soapenv:Body>

Perhaps it might look better to human eyes if it read:

<soapenv:Body>
   <echoreturn xmlns="blah1" xmlns:ns1="blah2">
    <ns1:vard>
     <ns1:vari>0</ns1:vari>
    </ns1:vard>
    <ns1:vard>
     <ns1:vari>0</ns1:vari>
    </ns1:vard>
    <ns1:vard>
     <ns1:vari>0</ns1:vari>
    </ns1:vard>
   </echoreturn>
  </soapenv:Body>

But the SOAP processor doesn't really care. The SOAP processor always 
converts the prefix into the namespace for processing. I'd be surprised if 
it caused any improvement in performance -- which is the only reason why I 
think it might be a relevant issue to discuss.

The elementFormDefault attribute determines whether or not local elements 
(elements defined within other structures) should be accessible as global 
elements. If you say elementFormDefault="unqualified", then local elements 
must not be qualified in the document instance. If you say 
elementFormDefault="qualified", then local elements must be qualified.

I know that a lot of folks use elementFormDefault="qualified" as a rule, 
but I'm not convinced this is a good practice. I think a better practice is 
to properly define your elements such that any element that you may need to 
access directly is defined as a global element.

You, as the writer of the schema, have complete control over which elements 
are local and which elements are global. Any element definition that is a 
direct child of the <schema> element is a global element. Any element 
definition that is not a direct child of the <schema> element (e.g., a 
child of <sequence>) is a local element.

If you feel it is necessary to be able to access a subelement directly, 
then you should define it as a global element. There are a lot of times 
when it doesn't make sense to expose an element as global. For example, it 
doesn't make sense to expose an element within an array as global -- 
because you need to understand the element's position within the context of 
the array.

Anne


At 03:16 AM 2/10/2004, you wrote:
>Do you think it is a good idea to hide (localize) namespaces by just making
>sure that all the schemas have set elementFormDefault="unqualified" to
>workaround the AXIS 1.1 problem of explicitly declaring the fully qualified
>namespace?
>
>
>
>
>Tony Opatha <to...@yahoo.com> wrote:
>Here's an example:
>
>
><soapenv:Body>
>   <echoreturn xmlns="blah1">
>    <ns1:vard xmlns:ns1="blah2">
>     <ns1:vari>0</ns1:vari>
>    </ns1:vard>
>    <ns2:vard xmlns:ns2="blah2">
>     <ns2:vari>0</ns2:vari>
>    </ns2:vard>
>    <ns3:vard xmlns:ns3="blah2">
>     <ns3:vari>0</ns3:vari>
>    </ns3:vard>
>   </echoreturn>
>  </soapenv:Body>
>
>As you can see namespace blah2 is declared in each of the elements, i.e.,
>as xmlns:ns1, xmlns:ns2, xmlns:ns3, rather just once as a global namespace
>that could be imported at the top level in the XSD spec.
>
>Any ideas if there is a workaround for AXIS 1.1?
>
>Thanks in adance for your response.
>
>
>Tony Opatha <to...@yahoo.com> wrote:
>Do you know why AXIS would include as part of each element it serializes 
>(in Doc/Lit SOAP) the fully qualified namespace rather than just the 
>namespace prefix?
>
>If we declare elementFormDefault as "qualified" in the XSD,
>AXIS should not need to include explicitly the fully-qualified
>namespace of the element that is defined as part of the
>specific namespace that is declared in the XSD schema, right?
>The namespace specific element schema is actually imported.
>
>Any ideas if there is a better way to workaround this problem?
>
>Do you think this is a valid behaviour for web service run-time, e.g., in 
>other
>products?
>
>
>Thanks.
>
>
>List:       <http://marc.theaimsgroup.com/?l=axis-user&r=1&w=2>axis-user
>Subject:    Re: xmlns=" " in the doc\literal SOAP message
>From: 
><http://marc.theaimsgroup.com/?a=105633916000001&r=1&w=2>"Dimuthu 
>Leelarathne" <muthulee () vijayaba ! cse ! mrt ! ac ! lk>
>Date: 
><http://marc.theaimsgroup.com/?l=axis-user&r=1&w=2&b=200309>2003-09-08 4:13:13
>[<http://marc.theaimsgroup.com/?l=axis-user&m=106301569616954&q=raw>Download 
>message RAW]
>
>It looks like a lot of discussion has been going on while I am away.
>
>It is news to me that this bug has been around for rpc\lit case. So I 
>checked out \
>with wrap\lit case and it is not there, i.e. wrap\literal does not send 
>any xmlns="". \
>I thought of just mentioning it to the list.
>
>Dimuthu.
>
>
>     Tony Opatha <to...@yahoo.com> wrote:
>     >Since elementFormDefault is "qualified" -- then one could safely 
> assume that \
>since >Axis generated this wsdl, it should also be serializing local 
>elements in the \
>appropriate >namespace...NOT adding xmlns="".
>
>     Is there any workaround for this currently?
>
>     That is exactly the problem I was identifying in AXIS previously (see 
> below). If \
>the elementFormDetail is qualified then we should not see explictly xmlns 
>attributes \
>in each element rather the namespace prefix should qualify the element 
>that is part \
>of the document instance in the SOAP Body.
>
>     This is especially problematic when we import additional schema from 
> other \
>namespaces and declare them in the document schema that will serialized as 
>part of \
>the SOAP Body by AXIS. I have observed that if you use directly A! XIS 
>SOAP APIs to \
>serialize the payload using the XSD schema this beahviour does not happen 
>(if you set \
>the QNames properly..), but it is jot the case using the AXIS messaging 
>pipeline (the \
>conventional way of processing SOAP payloads using WSDL).
>
>     >>Is there a way in AXIS to support only inclusion of namespace 
> prefix for \
>elements that  >>are defined in a namespace that is not the default 
>namespace rather \
>than explcitly  >>including the complete i.e., fully qualified namespace 
>for each \
>sub-element of the  >>document instance that is included in the SOAP Body?
>     >>
>     >>I would presume that either based on the XSD schema spec of the 
> document and/or
>     >>the WSDL interface spec AXIS would be able to use the namespace 
> prefix to \
>identify  >>that a particular element is associated in a particular namespace.
>
>
>     Anne Thomas Manes <an...@manes.net> wrote:
>       Cory,
>
>       You're correct. Please file a bug report.
>
>       Anne
>
>       At 10:05 AM 9/5/2003 -0500, you wrote:
>       >I think I now know what the source of Dimuthu's problem was/is -- 
> I've
>       >generated a doc/lit service in Axis and the schema that Axis 
> generates for
>       >a given service indicates that the elementFormDefault is 
> qualified, ie:
>       >
>       >
>       > > 
> targetNamespace="<http://test.xml.travelnow.com/>http://test.xml.travelnow.com" 
> \
>elementFormDefault="qualified">  >
>       >
>       >
>       >
>
>
>Do you Yahoo!?
>Yahoo! Finance: 
><http://us.rd.yahoo.com/evt=22055/*http://taxes.yahoo.com/filing.html>Get 
>your refund fast by filing online
>
>
>Do you Yahoo!?
>Yahoo! Finance: 
><http://us.rd.yahoo.com/evt=22055/*http://taxes.yahoo.com/filing.html>Get 
>your refund fast by filing online
>
>
>Do you Yahoo!?
>Yahoo! Finance: 
><http://us.rd.yahoo.com/evt=22055/*http://taxes.yahoo.com/filing.html>Get 
>your refund fast by filing online

~~~~~~~~~~~~~~~~~~
Anne Thomas Manes
VP & Research Director
Burton Group