managing verbose nature of xml

[Mick]

Hi All

I'm fairly certain this topic has been discussed before in this forum
before, and I would appreciate your patience in this matter.

I like XML and use it for various things, but haven't been able to
justify its verbose nature especially w.r.t. transmitting information
over the wire. (assuming there is no compression involved)

All I've been able to come up with is "Oh well, the benefits of using
it more than compensate for this trivial drawback!!! " but seriously,
I can't turn a blind eye to the 5 Megs file that I generate every day
to transfer data that I believe is only about 1.5 Megs.

If someone can share some thoughts, experiences, practices that you
have adopted in order to take care of this issue, I will highly
appreciate it.

regards
mick.

 

[Dave]

Hi All

I'm fairly certain this topic has been discussed before in this forum
before, and I would appreciate your patience in this matter.

I like XML and use it for various things, but haven't been able to
justify its verbose nature especially w.r.t. transmitting information
over the wire. (assuming there is no compression involved)

All I've been able to come up with is "Oh well, the benefits of using
it more than compensate for this trivial drawback!!! " but seriously,
I can't turn a blind eye to the 5 Megs file that I generate every day
to transfer data that I believe is only about 1.5 Megs.

If someone can share some thoughts, experiences, practices that you
have adopted in order to take care of this issue, I will highly
appreciate it.

regards
mick.

This might not be relevant but I have just moved some data from Access 97
into an XML format. The Access data base was 1.5MB and zipped 0.5MB. In XML
the file is 1.3MB, but zips to less than 0.2MB.

The repetitive nature for XML tags leads to very efficient compression
compared to other formats for storing data. The data as XML zipped is only
5% larger than the same data dumped into a delimited text file and zipped,
but the XML version gives a far better description of the data and is much
easier to handle.

Try comparing your own data XML and another format for size - but compare
the sizes compressed rather than expanded.

 

[Shmuel (Seymour J.) Metz]

I like XML and use it for various things, but haven't been able to
justify its verbose nature especially w.r.t. transmitting information
over the wire. (assuming there is no compression involved)

It's the nature of the beast. If you want something compact, then you
need a binary EDI format, but that would lock you out of a lot of
character-oriented software. If you want something that lets you
leverage existing HTML and SGML tools, then I don't see how you can
avoid the bloat.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to (e-mail address removed)

 

[GIMME]

Mick wrote :

If someone can share some thoughts, experiences, practices that you
have adopted in order to take care of this issue, I will highly
appreciate it.

One thing that comes to mind is that attributes take less
space than elements.

For example :

<this type="sometype" name="somename" value="somevalue"/>

Takes one line and 58 characters while this :

<this>
<type>sometype</type>
<name>somename</name>
<value>somevalue</value>
</this>

takes 5 lines and 84 characters.


The morale of the story is that if saving space is a premium
use attributes instead of elements whenever possible.

 

[Ed Day]

This is a problem for many users. The W3C thinks enough of this issue
that they created the XML-Binary working group. It's charter is to
look into creating a standardized binary representation of XML. This
would not replace XML, but would be used in situations such as yours
to provide an alternate, more compact encoding to allow things to be
done more efficiently.

This is still in the early stages and nothing has been produced yet.
For now, you are stuck with the verbose nature if you want to use XML.
The alternative is to use a different data representation format.

Regards,

Ed Day
Objective Systems, Inc.

 

[Mick]

I thank you all for responding and sharing your views about it. It is
certainly enriching.

Sometimes I wonder, and this might sound a bit knaive, but bear with
me for a moment - why do we need to describe each and every "object"
expressed in XML over and over again, the alternative in my mind is a
"definition handshake" - on demand _or_ as repeated every so often,
just not with e v e r y object. We can still keep it text-based and
"human readable" but not necesarily something you would want to
"write" in vi (something we don't do anyways).

It sounds like a cool thing to do to keep it simple, human readable
and writable in a simple notepad and all that jazz... but lets face it
.... all the language components that process xml also have to churn
through A L L of it (one could make the argument that this is less of
an issue since the processing power doubles every 12 months or
whatever and then we wonder 'darn it ... these software pieces are
getting very demanding')

For what its worth, for the record it does not mean that I will stop
using XML anytime soon, but stilll just wanted to see what ya'll think

Regards
Mick.

 

[Patrick TJ McPhee]

% Sometimes I wonder, and this might sound a bit knaive, but bear with
% me for a moment - why do we need to describe each and every "object"
% expressed in XML over and over again, the alternative in my mind is a

Because that's the nature of representing data using XML. If you
stop doing it, then you're no longer using XML.

[...]

% For what its worth, for the record it does not mean that I will stop
% using XML anytime soon, but stilll just wanted to see what ya'll think

Why not? What you're really asking is whether XML is suitable for
whatever purpose you're putting it to, and you're suggesting
that maybe it isn't.

What XML gives you is a complete syntax for encoding structured data
and pre-written parsers which can process that data. If you're using
it for data exchange, it makes it easy to pick out individual bits
of data. One could certainly define a different syntax for encoding data
which provides the same advantages but which might work better for
data interchange. It's probably been done.

 

[Garry Williams]

Have you tried YAML - www.yaml.org?

It's the nature of the beast. If you want something compact, then you
need a binary EDI format, but that would lock you out of a lot of
character-oriented software. If you want something that lets you
leverage existing HTML and SGML tools, then I don't see how you can
avoid the bloat.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to (e-mail address removed)