>Henry Zongaro wrote:
> Hi Curt,
>
> Co-incidentally, I started looking into Andy Heninger's prototype
code
> yesterday, and I'd like to volunteer to work on completing it.
There are a couple of things that I would like to do as part of the overall
project.
1. Port the NIST Java DOM Level 1 test suite to CppUnit.
In addition to testing the DOM implementation, this would find any usage
patterns (like the DOM_Node to DOM_Element casting) that wasn't supported.
The NIST/W3C DOM testing group is currently exploring possibilities to make
the test suite multilanguage, but a direct C++ port would be immediately
useful and could provide the group with feedback.
2. Align DOM_String with STL's basic_string<XMLCh> semantics
Since Andy said that his DOM will break existing app's, might as well take
advantage of the opportunity to change DOMString too. Basically, this says
that, at least, any method exposed in the public interface to DOMString
should have the same signature and work identically to a method in the
basic_string template. For performance reasons, the DOMString
implementation could be different, though I would love to find a way to
typedef DOMString as basic_string<XMLCh> while still maintaining the
optimizations of the current DOMString internally. That might involve using
a distinct internal string class within the DOM implementation.
I had taken a stab at that last year in an experimental version and could do
it again for testing and feedback. If I remember right there was a method
or two that I just didn't quite fathom in DOMString, but I could get the
thing working with either DOMString typedef'd as basic_string<XMLCh> (really
slow) or a DOMString based on the current implementation.
One interesting side effect of this, is that it causes transcode() to need
to find a new home. Which is probably a good thing considering how many
times its behavior comes up.
3. Implement DOM Events 2
This is my primary motivation for being in the DOM code at this time. If
the new DOM effort is moving, it would probably be best to add event support
to the new DOM and let the old DOM stall at DOM Level 1.
Probably the best thing for me to do is to prepare experimental versions of
these based on the existing DOM implementation and have them integrated into
the new DOM implementation as appropriate.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
