how to prevent "xmlns=''" from being serialized in the ASP.net WebService plumbing work.

[Jim Hsu]

when I use the XmlWebSerivce to response the xmlelement to Web Service client.
the ASP.net plumbing work ( the XmlSerializer in WebServices ) will serialize the XML

if we can control the wrapper class , I can set the XmlSchemaForm.N one or Qualified so that there will no be a 'xmlns=""' in the following namespace, but I don't know how to do that in WebService plumbing.

this null namespace will makes my web service wrapper class complains.
we need to fix it.

xmlns="http://www.cedar.com.t w/bluestar/">
- <BlueStar MsgName="Bank19 80" Status="9502" xmlns="">
<StatusCode>950 2</StatusCode>
<Severity>Error </Severity>
<StatusDesc>Sub mitXML - GetXMLTagName Failed!</StatusDesc>
</BlueStar>

Anyone can provide some help on this?
thanks in adv.

Jim

///<soapBox>it seems there are too many plumbing work in XML WebServices that is not configurable for developers, especially for us that pass XML, instead of .net Class. , SoapExtension seems to be the only solution....</soapBox>

[BjörnHolmberg]

Hello Jim!

The WS I'm working on right now is also returning XmlElement, but my WS-client is reading response
soap-xml directly without any proxy. In your case, what happens if your client treats the response
as an XmlElement, converts it to a string/stream, replaces xmlns="" with whatever You want it to be
and then creates a new XmlElement? I know it's just a workaround, but anyway.

I'm not exactly an expert but the impression I've got is that when you use soap extensions you are
working outside the .NET-WS infrastructure. For example what happens with Your automatic
asmx?WSDL-file and what about web service enhancements and the security infrastructure it's
promising?

/Regards Björn

[Jim Hsu]

there might be various ways the client of the WS is,
in fact, msxml parser and string might not experience significant issues,
but in System.net and XmlSerializer, default namespace and xmlns='' makes a
lot differnece.
my solution is now is with the XmlNoNamespaceW riter.
but that's a workaround.

thanks

-Jim

"BjörnHolmb erg" <bj************ *************** **@sulitelma.co m> wrote in
message news:40******** *******@sulitel ma.com...

Hello Jim!

The WS I'm working on right now is also returning XmlElement, but my WS-client is reading response soap-xml directly without any proxy. In your case, what happens if your client treats the response as an XmlElement, converts it to a string/stream, replaces xmlns="" with whatever You want it to be and then creates a new XmlElement? I know it's just a workaround, but anyway.
I'm not exactly an expert but the impression I've got is that when you use soap extensions you are working outside the .NET-WS infrastructure. For example what happens with Your automatic asmx?WSDL-file and what about web service enhancements and the security infrastructure it's promising?

/Regards Björn

[BjörnHolmberg]

Hello Jim! I made a google-search on XmlNoNamespaceW riter and found it on Kirk Allens blog. Seems to
be a good idea. But how can You plug in XmlNoNamespaceW riter into WS-plumbing?

By the way, here is a third workaround (fourth if we count soap extensions):

Instead of sending xml, it's possible to play by Microsoft rules and send objects instead of xml.
What You have to do then to get at xml is to use XmlSerializer on the object. This will decrease
performance since we will have first have deserialization (in plumbing) and then ask for
serialization again. But both seems to be fast in dotnet. I guess this will be ok for folks like me
that want to create xhtml from xml and xslt. But I don't know how it works for people that create
complicated web services by first designing their own xml-schemas...

Regards
Björn

Jim Hsu wrote:

there might be various ways the client of the WS is,
in fact, msxml parser and string might not experience significant issues,
but in System.net and XmlSerializer, default namespace and xmlns='' makes a
lot differnece.
my solution is now is with the XmlNoNamespaceW riter.
but that's a workaround.

thanks

-Jim

"BjörnHolmb erg" <bj************ *************** **@sulitelma.co m> wrote in
message news:40******** *******@sulitel ma.com...

Hello Jim!

The WS I'm working on right now is also returning XmlElement, but my

WS-client is reading response

soap-xml directly without any proxy. In your case, what happens if your

client treats the response

as an XmlElement, converts it to a string/stream, replaces xmlns="" with

whatever You want it to be

and then creates a new XmlElement? I know it's just a workaround, but

anyway.

I'm not exactly an expert but the impression I've got is that when you use

soap extensions you are

working outside the .NET-WS infrastructure. For example what happens with

Your automatic

asmx?WSDL-file and what about web service enhancements and the security

infrastructure it's

promising?

/Regards Björn