Curt Arnold wrote:
> >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.
>
This would be great, as long as it can be aligned with what the standards
bodies are doing.
>
> 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 think this is a bad idea. The performance improvement gained by using
plain XMLCh* for strings is pretty hard to reproduce with a custom string
class. I wrote a string class for Xalan called XalanDOMString which
essentially matches the semantics of std::basic_string (although it's not a
template class), and it has real performance problems. The beauty of using
an array of XMLChs is that it's very easy to optimize their allocation.
It's _much_ harder with a class. And don't forget that for DOM compliance
you must be able to represent a value as both "null" _and_ empty, so you
cannot just return a reference to an instance of a string class, you have
to return a pointer.
> 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.
You're welcome to use XalanDOMString -- I'd like there to be a common
string class that exists somewhere outside of both Xerces and Xalan for the
XML-related Apache projects to use. The only problem I see is that
XalanDOMString is implemented on top of vector<XMLCh>, so that might not be
acceptable for general use.
> 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.
Yes, I implemented global functions which return a vector<char> by value,
or populate a provided vector<char> instance. This doesn't solve the
problem of runtime libraries, since the destructors are in-line, but it
does mean that things won't leak. This might not be acceptable for Xerces,
since they don't currently use the collections in the Standard Library.
> 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.
I'd love to see this happen, but for it to be acceptable to Xalan, we'll
need to work out some of the details.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
