[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal

• From: Derek Denny-Brown <ddb@c...>
• To: David Megginson <ak117@f...>
• 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.

[snip]

>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 String[]s 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


     Derek E. Denny-Brown II      ||   ddb@c...
     "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:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Prev by Date: Re: XML application
• Next by Date: Re: XML application
• Previous by thread: Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
• Next by thread: Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
• Index(es):
  • Date
  • Thread