Next Round

[Tyler Baker]

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
Integer.parseInt(String s)).

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.

Tyler


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)