dotnet web services: Does anyone have any idea on how I can strip the extra whitespace in
the XML that shows up when I receive a response from an ASP.NET 2.0
webservice? This has been discussed before, but no one has ever come up
with a good answer to what seems like such a common question.

http://groups.google.com/group/microsoft.public.dotnet.framework.webservices/browse_thread/thread/b513edffdd5487c3/c2fff1b27460a421?lnk=gst&q=whitespace&rnum=1#c2fff1b27460a421
http://groups.google.com/group/microsoft.public.dotnet.framework.webservices/browse_thread/thread/ce6a8039023dbfb/c7240db31e1d3fe7?lnk=gst&q=whitespace&rnum=2#c7240db31e1d3fe7
http://groups.google.com/group/microsoft.public.dotnet.framework.webservices/browse_thread/thread/72cd867f6d30b9d0/0da3026a4d286e63?lnk=gst&q=whitespace&rnum=3#0da3026a4d286e63

It just seems very silly to have it included since another program will
be consuming it, and since that other program could care less about
whitespace. Not only is it a waste of bandwidth (albeit not _that_
much), but it causes serious implications for me when I try to parse
through the XML document in JavaScript.

For example, if the XmlDocument that I return has two nodes on it, the
child nodes of the root element of the response has five child nodes in
JavaScript when I parse the doc in Firefox (two are my elements, and
three are the whitespace). IE does return that there are two child
nodes, but the whitespace is still there nonetheless. I can code around
it by building a function that looks for the right tag name or that
ignores whitespace elements, but it's dumb that I'd have to do that in
the first place.

Also, contrary to the other posters, I am certain that in this case the
whitespace actually does come from the server and isn't being inserted
in the document for readability reasons or whatever. I've used Fiddler
and taken a look at the hex data that comes back, and, sure enough,
there is a <CRLF> at the end of every node and the indent spaces at the
beginning of every node.

Any takers on this question that seems to have been around forever
without a good answer?

[quoted text, click to view]

My answer would be that you're probably wasting more time thinking about
stripping whitespace than will ever be wasted in sending and receiving it.

Is this really the next most important thing you have to do? Is this the
next performance bottleneck in your application?

John

Like I said, it's not so much about bandwidth as much as it is a pain
to deal with in all of my JavaScript apps that count the whitespace as
actual nodes. It causes problems when I both iterate through the an
element's' child nodes as well as try to directly access a child node
by index. For example, when I send an XMLHTTPRequest to the server and
know that I'm only looking to get a single node back, I actually have
to either a) get childNode[1] instead of childNode[0], b) call
Prototype's Element.cleanWhitespace() on the parent node (which doesn't
handle recursive nodes for XML well it seems), or c) check the nodeType
in each one of my nodes manually in a loop. As I said, there are ways
around it, but doesn't it seem odd to anyone that it's not easily
disabled?

The only reason I ask all this is because it's a constant pain in my
side to have to program around it every time. If there was something I
can do globally per server or web.config that would strip out the
useless whitespace, it would ultimately save me much more time than
having to code around it in every single one of my apps.


On Nov 6, 8:33 pm, "John Saunders" <john.saunders at trizetto.com>
[quoted text, click to view]