Lists Home |
Date Index |
- From: Tyler Baker <email@example.com>
- To: Don Park <firstname.lastname@example.org>
- Date: Thu, 21 Jan 1999 02:13:48 -0500
Don Park wrote:
> >First, we will need to define a new type, namely Name.
> Turning names into first class objects does solve the namespace problem as
> well as providing an opportunity to solve the 'intern' problem by adding
> name comparison methods. Implementations that maintains 'interned' name
> within Name will obviously be very efficient past the tree building process.
> It is not a very well known fact that Docuverse DOM SDK uses 'interned'
> names and it has been very useful to many of our customers although it does
> cost about 10% speed penalty during tree building.
> Going beyond the Name interface, I would love to have Data interface which
> does not force the content data to be turned into 'String' unnecessarily.
I have had exactly this in my parser interface for a while, namely a
CharacterData interface. It has methods for retrieving the content as a
character arrays, Strings, normalized character arrays, normalized strings, and
support for direct parsing of characters into primitive values like ints,
booleans, and floats (this support is there so you are not forced to create a new
String object just to parse content into a number with methods like
Not sure if this would be in the realm of SAX since SAX is supposed to be a
Simple API for XML, but some sort of character data interface with a lazy data
model behind it that at least supports new character arrays, copying, strings,
and normalized content would not be such a bad idea.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)