Problems in transferring XML

[comp.text.xml]

Hi,
I'm developing a system uses SOAP took kit version 3. The XML is
transferred
between the server and the client.
We have noticed when transferring data using SOAP a considerable amount
of
time is spent on encoding decoding the XML string.

And in the text transferred strings like &, " gt;...etc are
repeated over and over again.
What would be the best ways to reduce this processing the amount of
data
transferred?
How can we overcome the repetition of these strings?

Any help would be greatly appreciated.
Regards,
Nadee

[Joe Kesselman]

What would be the best ways to reduce this processing the amount of

data transferred?

Well, the traditional solution is to put the XML thru standard data
compression algorithms (zip/unzip, for example) before sending it across
the wire. That will reduce repeated structure as well as repeated
strings, and is thus much more effective than just trying to compress
the text content.

The question of whether there should be a standardized compressed form
for XML comes up on a regular basis. Most past attempts have actually
not been much, if any, improvement over zip/unzip. Folks still play with
this periodically, and the W3C's still debating whether the concept
makes any sense or if it completely breaks the XML processing model.

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

[comp.text.xml]

Hi,

Thanks for your idea.
But still im not clear about the solution.
How can I compress XML using a compression algoritm?
Is it after saving the XML string to a file and then zip it? But in
that case how are we going to transfer the zipped file?
I tried to send the zipped file as a string but SOAP tool kit returned
and error saying the string contains some invalid characters.

Please advice.

Joe Kesselman wrote:

What would be the best ways to reduce this processing the amount of
data transferred?

Well, the traditional solution is to put the XML thru standard data
compression algorithms (zip/unzip, for example) before sending it across
the wire. That will reduce repeated structure as well as repeated
strings, and is thus much more effective than just trying to compress
the text content.

The question of whether there should be a standardized compressed form
for XML comes up on a regular basis. Most past attempts have actually
not been much, if any, improvement over zip/unzip. Folks still play with
this periodically, and the W3C's still debating whether the concept
makes any sense or if it completely breaks the XML processing model.

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

[Joseph Kesselman]

comp.text.xml wrote:

I tried to send the zipped file as a string but SOAP tool kit returned
and error saying the string contains some invalid characters.

I don't know which language you're working on, but you can probably get
an in-memory implementation of zip or a similar algorithm. Java comes
with one.

Zipped data uses all 256 byte values, including some which XML 1.0
doesn't like. You'll have to escape some characters, at least, and will
probably have to do a base-64 encoding, to include it in a SOAP message.
(There are recent proposals to allow enclosing arbitrary binary data
alongside the SOAP message.) Conversion to and from base-64 is also
available in off-the-shelf implementations.

>
Please advice.

Joe Kesselman wrote:

>>>What would be the best ways to reduce this processing the amount of
data transferred?

Well, the traditional solution is to put the XML thru standard data
compression algorithms (zip/unzip, for example) before sending it across
the wire. That will reduce repeated structure as well as repeated
strings, and is thus much more effective than just trying to compress
the text content.

The question of whether there should be a standardized compressed form
for XML comes up on a regular basis. Most past attempts have actually
not been much, if any, improvement over zip/unzip. Folks still play with
this periodically, and the W3C's still debating whether the concept
makes any sense or if it completely breaks the XML processing model.

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden

[comp.text.xml]

Hi Joseph,

My application is written in VFP 9.
Best regards,
Nadee
Joseph Kesselman wrote:

comp.text.xml wrote:

I tried to send the zipped file as a string but SOAP tool kit returned
and error saying the string contains some invalid characters.

I don't know which language you're working on, but you can probably get
an in-memory implementation of zip or a similar algorithm. Java comes
with one.

Zipped data uses all 256 byte values, including some which XML 1.0
doesn't like. You'll have to escape some characters, at least, and will
probably have to do a base-64 encoding, to include it in a SOAP message.
(There are recent proposals to allow enclosing arbitrary binary data
alongside the SOAP message.) Conversion to and from base-64 is also
available in off-the-shelf implementations.

Please advice.

Joe Kesselman wrote:

>>What would be the best ways to reduce this processing the amount of
data transferred?

Well, the traditional solution is to put the XML thru standard data
compression algorithms (zip/unzip, for example) before sending it across
the wire. That will reduce repeated structure as well as repeated
strings, and is thus much more effective than just trying to compress
the text content.

The question of whether there should be a standardized compressed form
for XML comes up on a regular basis. Most past attempts have actually
not been much, if any, improvement over zip/unzip. Folks still play with
this periodically, and the W3C's still debating whether the concept
makes any sense or if it completely breaks the XML processing model.

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden

[Joe Kesselman]

My application is written in VFP 9.

Oh well. I'm completely unfamiliar with VFP, so my ability to advise you
is strictly limited to the architectural level.

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

[comp.text.xml]

Hi,

I mange to zip the data and get it into a string. But I get an error
when I pass this to the SOAP.
OLE IDispatch exception code 0 from Server: Server:XML Parser failed at
linenumber 1, lineposition 631, reason is: Illegal xml character.
HRESULT=0x80004005: Unspecified error
- Server:Loading the request into SoapReader failed.
HRESULT=0x80070057:
The parameter is incorrect.
- Server:One of the parameters supplied is invalid.
HRESULT=0x80070057: The
parameter is incorrect.
...

Im using the (encoding="Windows-1252"). Also tried to send this in a
CDATA section.
Both failed. Any ideas on this?
Best regards,
Nadee

Joseph Kesselman wrote:

comp.text.xml wrote:

I tried to send the zipped file as a string but SOAP tool kit returned
and error saying the string contains some invalid characters.

I don't know which language you're working on, but you can probably get
an in-memory implementation of zip or a similar algorithm. Java comes
with one.

Zipped data uses all 256 byte values, including some which XML 1.0
doesn't like. You'll have to escape some characters, at least, and will
probably have to do a base-64 encoding, to include it in a SOAP message.
(There are recent proposals to allow enclosing arbitrary binary data
alongside the SOAP message.) Conversion to and from base-64 is also
available in off-the-shelf implementations.

Please advice.

Joe Kesselman wrote:

>>What would be the best ways to reduce this processing the amount of
data transferred?

Well, the traditional solution is to put the XML thru standard data
compression algorithms (zip/unzip, for example) before sending it across
the wire. That will reduce repeated structure as well as repeated
strings, and is thus much more effective than just trying to compress
the text content.

The question of whether there should be a standardized compressed form
for XML comes up on a regular basis. Most past attempts have actually
not been much, if any, improvement over zip/unzip. Folks still play with
this periodically, and the W3C's still debating whether the concept
makes any sense or if it completely breaks the XML processing model.

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden