[
Lists Home |
Date Index |
Thread Index
]
- To: <xml-dev@lists.xml.org>
- Subject: RE: [xml-dev] Xml file sizes
- From: "Byarlay, Wayne A." <wab@purdue.edu>
- Date: Mon, 21 Nov 2005 16:14:49 -0500
- Thread-index: AcXu3Rprgrp6KGdMQduY8RNo0W/FTwAAj5qQ
- Thread-topic: [xml-dev] Xml file sizes
Well, I've certainly received a well-voiced response. It would seem that
XML's readability is its strongest point. Both by people, and computers.
If its original design was more for ease-of-use, than straight-out
efficiency, that would make sense.
Thanks for your input! Though, right now, I cannot think of any
applications for XML in any of my current projects, I will keep it in
mind.
wab
-----Original Message-----
From: Michael Champion [mailto:michael.champion@hotmail.com]
Sent: Monday, November 21, 2005 3:50 PM
To: Byarlay, Wayne A.; xml-dev@lists.xml.org
Subject: RE: [xml-dev] Xml file sizes
>From: "Byarlay, Wayne A." <wab@purdue.edu>
>To: <xml-dev@lists.xml.org>
>Subject: [xml-dev] Xml file sizes
>Date: Mon, 21 Nov 2005 14:31:13 -0500
>
>If XML uses tags such as <blablabla>This is my data</blablabla>, is
>that not a lot of extra bytes to simply declare the end of a field?
The XML spec explicitly says something like "terseness is not a design
objective." In this case, I think there were a number of recovering
LISP
victims :-) who wanted a way for *humans* to figure out what level of
the hierarchy was being closed.
>
>And to take it a step further: if I have several records, but the
>fields are always sequential, such as:
><my record>
> <field1>Bubba Smith</field1>
> <field2>123 Elm Street</field2>
></my record>
><my 2nd record>
> <field1>Sally Ryder</field1>
> <field2>123 Elm Street</field2>
></my 2nd record>
>
>...Wow, to me, that just seems like many redundant bits of data. So,
>how is XML better than, say, a file where the field headers (and
>footers) are smaller?
If the data is always that regular and sequential, there is little
advantage to XML. But what if there are multiple versions of a format
floating around (some with extra information columns), and you need to
figure out which is which? What if you need to merge them? What if
some "cells" are the top of a tree of subordinate information? That
gets dicey with CSV.
The basic reason why XML is practical is that it is a good enough format
for a lot of things, even if it is not particularly good at anything.
Humans can deal with it (albeit by squinting a lot), and software can
deal with it (albeit inefficiently). It's particularly suited for the
messy middle ground where both computers and humans must work with
information that is somewhat document-like and somewhat data-like, and
there is enough structure and semantics built into the format to be
useful but not enough structure to be easily mapped into RDBMS, CSV,
ASN.1, etc.
_________________________________________________________________
Don't just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
|