Prai Jei wrote:
> That sort of thing but there are a few more fields requested. The 
> verbosity of the output format is significant if the data has to be
> transmitted across a s---l---o---w wide area network connection. Ties
> up the till too long, customers leave the checkout queue and walk
> out.

If it is a business requirement to transmit the data in real time to 
somewhere else, then it is a business requirement to install a faster 
connection...or...

> We get round that by having the sales information written first to a
> PC on the local network (fast) which then relays it to the target
> system in its own time.

...use an alternative solution; this one sounds like a good idea.

The terseness aspect of XML was discussed at length during development.
The assumption was that network speeds would get faster in the future,
which they have, but not everywhere (I was staying last week in the UK,
in a location with only 48Kb/s dialup :-), but as Stefan suggests, a
compression stream can help, as plaintext data like XML typically
compresses very well. Another possibility is use terser markup and
convert it the other end, eg

<t n="abc123"><i c="xyz789" q="3" p="29.99" a="1234567890"/></t>

or even just send CSV as you suggested, and convert to XML the other
end, but this may introduce its own redundancy if fields have to be
repeated in the normal form.

///Peter
-- 
XML FAQ: http://xml.silmaril.ie/

Followups to a.u.e removed