9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Roger Flores <roger.flores@pacbell.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] OT: small xml parser found!
Date: Thu, 19 Feb 2004 10:28:18 +0000	[thread overview]
Message-ID: <eV_Yb.14676$qF5.11120@newssvr29.news.prodigy.com> (raw)
In-Reply-To: <1dac8c6094aba121c8f564e3cb3b8142@vitanuova.com>

<rog@vitanuova.com> wrote in message
news:1dac8c6094aba121c8f564e3cb3b8142@vitanuova.com...
> not to mention that the source #includes the non-existent "host.h" (i
> think "ali_config.h" is intended)

Ooops.  Yes, ali_config.h, was intended.  The only other header file, ali.h,
is already included.  Host.h is a file I use to allow Ali to compile in Palm
OS apps.


>non-ANSI header files

Hmmm.  Searching around for a list of ANSI header files I see this:
http://www.cplusplus.com/doc/ansi/hfiles.html
I see two headers are not in that list.  malloc.h apparently should be
stdlib.h, so I'll change that.  Thanks.  The other is stdint.h, which is a
C99 standard.  I used to just define my own types (like int32 with no stupid
_t) but the stdint.h types are "standard" and so usually understood.  I
included #defines for the types for those lacking a stdint.h header file.

> references undefined types

I assume these are the just mentioned stdint.h types?


>and generally doesn't give the impression of stability.

The alpha standing on SourceForge is intended to reflect my contentness with
the feature set versus a 1.0 release.  I do not know of any bugs and those
that will be found can be fixed.


> or that it doesn't appear to give any means of accessing element
attributes.

Sure it does.  Just extend the address book example from the web page where
it reads the "id" attribute from the "person" element.  Say you want to read
<phone type="home">1234567</phone>.  Add a line like this to parse_person():

   if (!doc->error) ali_in(doc, personN, "^e%f", 0, "phone", parse_phone);

And then add a function to to parse the phone number element.  A function is
used because the element is complex instead of simple.

static void
parse_phone(ali_doc_info *doc, ali_element_ref phoneN, void * data, bool
new_element)
{
   my_person_struct * person = last_person(data);
   if (!doc->error) ali_in(doc, phoneN, "^a%s", 0, "type",
&person->phone_type);
   if (!doc->error) ali_in(doc, phoneN, "%d", &person->phone_number);
}

I think some might prefer a notation like "^e^a%s%d" instead of creating a
function.  I've added support in Alo for such syntactical sugar but not in
Ali yet.


> erm, forgive me for demurring, but 1898 lines doesn't
> strike me as "small", especially given that (from the source):

I think Ali is "small" compared to other XML parsers.  Can you find another
that is close?  Remember that nothing about XML is small! :)

If you can live with the restrictions and minimal features then you can save
a lot of program size and probably code writing.  If your XML data can come
from anywhere or you need the missing features or don't care about size then
use something like Expat because it will work better for you.  I just find
that my apps' code + Ali + Alo are still smaller than Expat!


Thanks for the comments and let me know if you find anything else.

-Roger Flores


  parent reply	other threads:[~2004-02-19 10:28 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-17 13:50 steve-simon
2004-02-18 18:17 ` Roger Flores
2004-02-18 20:43   ` rog
2004-02-18 20:42     ` David Tolpin
2004-02-19 15:29       ` rog
2004-02-19 15:27         ` Gorka Guardiola Múzquiz
2004-02-19 15:31           ` boyd, rounin
2004-02-19 16:14             ` Rob Pike
2004-02-19 16:16             ` Rob Pike
2004-02-19 16:18               ` David Tolpin
2004-02-19 16:20               ` boyd, rounin
2004-02-19 15:54           ` John Murdie
2004-02-19 16:14             ` C H Forsyth
2004-02-19 16:24               ` John Murdie
2004-02-19 16:17             ` David Tolpin
2004-02-20  2:36               ` boyd, rounin
2004-02-19 17:15             ` rog
2004-02-19 17:20               ` David Tolpin
2004-02-19 17:31                 ` rog
2004-02-19 17:30                   ` David Tolpin
2004-02-19 17:45                     ` rog
2004-02-19 17:39                   ` C H Forsyth
2004-02-19 15:27         ` David Tolpin
2004-02-19 10:28     ` Roger Flores [this message]
2004-02-19  9:59 plan9fans
2004-02-19 10:13 ` David Tolpin
2004-02-19 11:04 ` Dave Lukes
2004-02-19 11:41   ` matt
2004-02-19 12:36     ` Dave Lukes
2004-02-19 13:45       ` C H Forsyth
2004-02-20  8:22         ` Martin C.Atkins
2004-02-19 10:31 plan9fans

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='eV_Yb.14676$qF5.11120@newssvr29.news.prodigy.com' \
    --to=roger.flores@pacbell.net \
    --cc=9fans@cse.psu.edu \
    /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;
as well as URLs for NNTP newsgroup(s).