OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

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

[ Lists Home | Date Index | Thread Index ]
  • From: Derek Denny-Brown <ddb@criinc.com>
  • To: David Megginson <ak117@freenet.carleton.ca>
  • 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@criinc.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:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS