Lists Home |
Date Index |
- From: Derek Denny-Brown <email@example.com>
- To: David Megginson <firstname.lastname@example.org>
- Date: Mon, 15 Dec 1997 10:40:16 -0800
At 09:01 PM 12/13/97 -0500, David Megginson wrote:
>Tim Bray writes:
> > > attribute(XmlParser, String, String, boolean)
> > It seems completely wrong to have an attribute event separate from
> > start-element events.
>I could send a hashtable of attribute names and values with the
>startElement() callback, and let users look up types (etc.) with my
>query methods, but I would have to lose a bit on two counts:
>1) Allocating a new hashtable for every start tag will slow down the
> parser a fair bit.
>2) I'd have no way to show which attributes were specified and which
> were defaulted (see below).
> > What's the boolean? I don't think the application author should
> > to have to deal with anything but the name and value of attributes.
I can imagine two relatively simple solutions.
1) Have your element evetn callback return a switch (boolean) to indicate
if attributes are wanted or not. Have seperate code for each options
(minor bloating in exchange for speed) and also have a finished-start-tag
event which is oly fired when the processor (event-handler) asked for
attributes. I am not sure of the utility of this since every SGML/XML
application I have written uses attributes on many of it's component elements.
2) Rather than using a hash table, use a recursive parse routine over the
attributes which unwinds to put the attribute names and values into a pair
of String's. The recursive parse is so that you can use the stack as a
temporary holding place for the names and values until you know how many
there are. alternatively you could have one common pair of Strings which
are used by every element event. You allocate them to a default size and
grow them if need be. You never really need to shrink them. The bloat to
your current code is more significant for this technique, but it increases
usability with little performance hit.
Derek E. Denny-Brown II || email@example.com
"Reality is that which, || Seattle, WA USA
when you stop believing in it, || WWW/SGML/HyTime/XML
doesn't go away." -- P. K. Dick || Java/Perl/Scheme/C/C++
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)