From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
From: Roger Flores <roger.flores@pacbell.net>
Message-ID: <eV_Yb.14676$qF5.11120@newssvr29.news.prodigy.com>
References: <bWNYb.14404$pt6.3250@newssvr29.news.prodigy.com>, <1dac8c6094aba121c8f564e3cb3b8142@vitanuova.com>
Subject: Re: [9fans] OT: small xml parser found!
Date: Thu, 19 Feb 2004 10:28:18 +0000
Topicbox-Message-UUID: ed553bd4-eacc-11e9-9e20-41e7f4b1d025

<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