Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Felix Lee <felix.1@canids.net>
To: gdb@sources.redhat.com
Subject: Re: GDB/XMI (XML Machine Interface)
Date: Sun, 22 Aug 2004 02:55:00 -0000	[thread overview]
Message-ID: <20040822025527.96F5D511B4A@stray.canids> (raw)
In-Reply-To: message on Sat, 21 Aug 2004 14:28:52 PDT from Felix Lee <felix.1@canids.net>

Felix Lee <felix.1@canids.net>:
> Bob Rossi <bob@brasko.net>:
> >    1. Have to write a parser. (regex, recursive decent)
> >       BTW, I guarantee the parser will have to be updated with every
> >       release of GDB.
> so far, I haven't found that xml is any less work than that, and
> it usually feels like a lot more work, but I haven't used xml for
> anything substantial yet, so it may just be unfamiliarity.

here's some elaboration.  this is what I think about xml parsers
today.  please correct me if I'm wrong.

there are two types of xml parsers, stream-based and tree-based.

using an xml stream parser is equivalent to writing a recursive
descent parser.  the stream parser basically just handles the
'tokenization' aspect of parsing xml (which is complicated by
considerations like character encoding, etc.)

to read data with an xml stream parser, you have to write
handlers that match the structure of the data you're parsing,
which is not any simpler than writing a recursive descent parser
for some other tree-like data format.

using an xml tree parser is complicated by xml's origin as a
markup language, which introduces issues that aren't particularly
relevant to data representation, but can't easily be ignored.

something like perl's XML::Simple tries to hide the messy details
and give you a natural data structure that corresponds to an xml
document, but there are a few problems that make XML::Simple
unsuitable for data that isn't "simple".

using a more general xml tree parser is harder.  in order to
access the data you want, you either have to walk the document
tree yourself (which is similar to writing a recursive descent
parser) or use XPATH descriptions to locate items in the tree
(which is similar to using regexps).

xml tree parsers also have the disadvantage of needing a lot of
memory.  the estimates are 10x to 30x the size of the xml
document, which puzzles me.  it's not clear to me why you'd need
more than about 2x.  (actually I'd expect more like 0.8x since
xml is redundantly verbose.)

with either stream parsers or tree parsers, if an xml schema
changes, you have to revise your code, unless the change is
careful to make only backward-compatible extensions.
guaranteeing that is hard for nontrivial changes, so people often
screw it up, or they play it safe and define a new schema.  in
either case, old code will often require updating anyway.
--


             reply	other threads:[~2004-08-22  2:55 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <message on Sat, 21 Aug 2004 14:28:52 PDT from Felix Lee <felix.1@canids.net>
2004-08-22  2:55 ` Felix Lee [this message]
2004-08-23  0:33   ` Bob Rossi
2004-08-23  9:27   ` Fabian Cenedese
     [not found] <5956F1E2-EB0D-11D8-9949-000A9569836A@apple.com>
2004-08-11  0:51 ` Chris Friesen
     [not found]   ` <gdb001@speakeasy.net>
2004-08-11  6:28     ` Felix Lee
2004-08-11  8:25       ` Chris Friesen
2004-08-11 22:43     ` Felix Lee
2004-08-20 10:34     ` Felix Lee
2004-08-20 12:54       ` Bob Rossi
2004-08-20 18:34         ` Daniel Jacobowitz
2004-08-20 18:49           ` Bob Rossi
2004-08-20 18:52             ` Daniel Jacobowitz
2004-08-20 19:25               ` Bob Rossi
2004-08-20 19:42                 ` Daniel Jacobowitz
2004-08-20 19:59                   ` Bob Rossi
2004-08-21 10:25                     ` Eli Zaretskii
2004-08-21 12:34                       ` Bob Rossi
2004-08-21 13:34                         ` Eli Zaretskii
     [not found]           ` <drow@false.org>
2004-08-20 19:06             ` Felix Lee
2004-08-20 19:09               ` Daniel Jacobowitz
2004-08-20 19:20             ` Felix Lee
2004-08-21 12:37               ` Bob Rossi
     [not found]         ` <bob@brasko.net>
2004-08-20 18:20           ` Felix Lee
2004-08-20 21:34           ` Felix Lee
2004-08-21 19:21           ` Felix Lee
2004-08-21 20:21             ` Bob Rossi
2004-08-21 19:28           ` Felix Lee
2004-08-21 20:16             ` Bob Rossi
2004-08-21 21:28           ` Felix Lee
2004-08-21 22:37           ` Felix Lee
     [not found] <1092177534.30930.ezmlm@sources.redhat.com>
2004-08-10 23:02 ` Jim Ingham
2004-08-10 20:14 Bob Rossi
2004-08-10 22:38 ` Kip Macy
2004-08-11  0:17 ` Michael Chastain
2004-08-11  7:36 ` Fabian Cenedese
2004-08-11  8:51 ` Nick NoSpam
2004-08-11 18:05 ` Bob Rossi
2004-08-11 19:26   ` Alain Magloire
2004-08-11 22:35     ` Jason Molenda
2004-08-12 13:03       ` Nick NoSpam
2004-08-19 23:49 ` Bob Rossi
2004-08-20  7:09   ` Chris Friesen
2004-08-20 12:47     ` Bob Rossi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040822025527.96F5D511B4A@stray.canids \
    --to=felix.1@canids.net \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox