XML size (was: no subject)

[Derek Atkins]

Bill,

This is yet another reason I was to use embedded SQL..  You get
the ability to dump/reload your data via a text editor if you
so choose.

Just like with the kernel _source_, the user is changing a
representation of the data file.  It is not changing the actual data
itself (the binary kernel).  A user who goes to change the kernel has
to run it through a data processor (the compiler) to put it into a
state where it can be used by the application (the computer).

Similarly, I propose the same process for here.  The user who wants to
manually adjust their data first converts it into a format they can
use (db_dump), edits it, and then converts it back into a format that
the application can use (db_restore).

How is this any different?

The application should be able to store the data in any format it so
desires in order to make data access speedups and other tradeoffs.

So long as there exists a way to convert back-and-forth between that
format and an human format (e.g. SQL) then what is the issue?

Note that I _have_ been arguing for using SQL; just _embedded_ SQL.

-derek

Bill Gribble <grib@linuxdevel.com> writes:

> On Wed, 2002-04-03 at 08:54, Derek Atkins wrote:
> > Note that this will not only fail to do what you want, but could leave
> > your data file unreadable and unusable.  This is _EXACTLY_ the kind of
> > thing that we DON'T want people to be doing!  If you want to change
> > your data you should use the application to do it.  
> 
> Extremely Strongly Disagree.
> 
> I think it's a fundamental part of the Unix and free software philosophy
> that the data belongs to the user, not to the application.  "It's none
> of your d**n business what I do with my data!"  If the user wants to
> pipe their data through perl or sed or whatnot that's their business.
> 
> That's the main reason *I* wanted to go to the XML format to start
> with.  People *hate* applications that bottle their data up in opaque
> formats.  Databases get a special exemption because of the extremely
> delicate nature of the interrelationships between bits of data, but all
> real dbs have a way to dump text (SQL) that can be used to exactly
> restore the db.  Not just a text "export" (which is usually lossy) but a
> dump which exposes all of the data's guts. 
> 
> Sure, it's ill-advised to make precipitous changes to your XML data
> file, but it's also ill-advised to make precipitous changes to the
> kernel source code... does that mean it shouldn't be available for easy
> editing? 
> 
> b.g.
> 
> 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available