Discussion:
Returning XML from a SOAP call
(too old to reply)
Peter Olcott
2009-01-08 12:20:26 UTC
Permalink
Is there any way to return XML from a SOAP call without the
special characters such as "<" being encoded as &lt; ???
Joe Fawcett
2009-01-09 08:37:14 UTC
Permalink
Is there any way to return XML from a SOAP call without the special
characters such as "<" being encoded as &lt; ???
To be valid XML they have to encoded or within a CDATA section, but that
only applies to text within elements. So if you were crafting your own
service you could force a CDATA section for the elements in question but
attribute values would still have to be encoded. I don't know of any of the
popular SOAP frameworks that allow you to specify CDAT sections in their
configuration.
--
Joe Fawcett
http://joe.fawcett.name
Peter Olcott
2009-01-09 11:18:31 UTC
Permalink
Post by Joe Fawcett
Post by Peter Olcott
Is there any way to return XML from a SOAP call without
the special characters such as "<" being encoded as &lt;
???
To be valid XML they have to encoded or within a CDATA
section, but that only applies to text within elements. So
if you were crafting your own service you could force a
CDATA section for the elements in question but attribute
values would still have to be encoded. I don't know of any
of the popular SOAP frameworks that allow you to specify
CDAT sections in their configuration.
The system that we are using is gsoap.
Post by Joe Fawcett
--
Joe Fawcett
http://joe.fawcett.name
Joe Fawcett
2009-01-10 10:30:39 UTC
Permalink
Post by Peter Olcott
Post by Joe Fawcett
Is there any way to return XML from a SOAP call without the special
characters such as "<" being encoded as &lt; ???
To be valid XML they have to encoded or within a CDATA section, but that
only applies to text within elements. So if you were crafting your own
service you could force a CDATA section for the elements in question but
attribute values would still have to be encoded. I don't know of any of
the popular SOAP frameworks that allow you to specify CDAT sections in
their configuration.
The system that we are using is gsoap.
Not one I've come across. But the fact is that either you need non
well-formed 'XML', in which case no self-respecting system will do that, or
you can use CDATA, which is only a convenience anyway. No XML parser will
care whether you have: <data> 1 & l t ; 2</data> (spaces for readability) or
<data><![CDATA[ 1 < 2 ]]></data>
Strive to fix whatever system needs non well-formed XML to operate or we'll
end up with the same problems that beset us with browsers that repair bad
HTML.
--
Joe Fawcett (MVP - XML)
http://joe.fawcett.name
Peter Olcott
2009-01-10 20:02:21 UTC
Permalink
Post by Joe Fawcett
Post by Peter Olcott
Post by Joe Fawcett
Post by Peter Olcott
Is there any way to return XML from a SOAP call without
the special characters such as "<" being encoded as
&lt; ???
To be valid XML they have to encoded or within a CDATA
section, but that only applies to text within elements.
So if you were crafting your own service you could force
a CDATA section for the elements in question but
attribute values would still have to be encoded. I don't
know of any of the popular SOAP frameworks that allow
you to specify CDAT sections in their configuration.
The system that we are using is gsoap.
Not one I've come across. But the fact is that either you
need non well-formed 'XML', in which case no
self-respecting system will do that, or you can use CDATA,
which is only a convenience anyway. No XML parser will
care whether you have: <data> 1 & l t ; 2</data> (spaces
for readability) or
None of several XML parsers are correctly parsing this form
as XML, they are all parsing it as strings of text. In my
case I have valid XML that is returned by a SOAP call. All
of the special XML characters such as "<" and ">" are
translated into &lt; and &gt; respectively, thus they are
not recognized by the XML parsers as XML element brackets.
Post by Joe Fawcett
<data><![CDATA[ 1 < 2 ]]></data>
Strive to fix whatever system needs non well-formed XML to
operate or we'll end up with the same problems that beset
us with browsers that repair bad HTML.
--
Joe Fawcett (MVP - XML)
http://joe.fawcett.name
Loading...