[Xalan-C++] Upcoming major interface changes

[Da...@lotus.com]

I just wanted to give everyone a heads-up about changes in the XalanDOM
interfaces.  XalanNode and its derivatives will no longer use the
XalanDOMString class for string values -- instead we'll return and accept
pointers to wide strings (const XalanDOMChar*).

This will not affect those people using the processor as is.  It will only
affect anyone using the XalanDOM classes to create their own implementation
classes.  I apologize for this major upheaval in the interfaces, but it's
motivated by three things:

   1. Distinguishing between an empty string and a "null" string.

     The DOM recommendation distinguished between a null namespace value
     and an empty namespace value.  This is clearly pretty difficult to do
     with references to XalanDOMStrings.  We could return pointers to
     XalanDOMStrings, or use some known "null" XalanDOMString instance, but
     that seems really awkward to me.  This is really my fault, because at
     the time I decided to use XalanDOMStrings in the interfaces, I wasn't
     aware of this distinction in the DOM.

   2. Performance.

     Performance will be increased by using arrays of XalanDOMChars instead
     of XalanDOMStrings, as it will be easier to control how memory is
     allocated.  For example, we can use an allocator that is not
     thread-safe for building the document.  Since our current
     XalanDOMString implementation is built on top of std::vector, it's
     much more difficult to use a custom allocator.

   3. Alignment with Xerces.

     The Xerces team is experimenting with a new set of DOM interfaces that
     use wide string pointers.  Those with some history with Xerces and
     Xalan will know that the current Xerces DOM has no abstract base
     classes.  The new Xerces DOM changes this.  Once that's been
     incorporated into Xerces, we can get rid of the XalanDOM classes and
     derive directly from the Xerces abstract base classes.  This will
     allow much better performance when users want to transform a DOM,
     since we won't be required to wrap their classes with our current
     proxy classes.  It will also remove quite a bit of code from Xalan,
     which I think is a very good thing.

I'd love to hear from anyone who has any opinions on this, pro or con.  The
plan would be to integrate these changes in the next major Xalan-C++
release, which will probably not be for a while.

Dave

Re: [Xalan-C++] Upcoming major interface changes

[Jon Smirl <jo...@mediaone.net>]

From: <Da...@lotus.com>
>    1. Distinguishing between an empty string and a "null" string.

I've been noticing differences between Xalan and XT when testing for an
undefined parameter vs one set to an empty string, this is probably related.

>    3. Alignment with Xerces.

Does this mean a third, base DOM class project is going to be created?

Also, what do you think about using a portable run-time from another
project, such as Mozilla's NSPR
http://www.mozilla.org/projects/nspr/reference/html/index.html or the Apache
server's APR (each about 100KB)? This might allow all of the platform
dependent code to be removed. It seems kind of pointless to use developer
resources maintaining an independent mini run-time when there are good
alternatives available.

Jon Smirl
jonsmirl@mediaone.net

Re: [Xalan-C++] Upcoming major interface changes

[David Braaten <da...@multiactive.com>]

I would much rather see the internals of XalanDOMString changed,
rather than dropping it completely.
Alternatively, class a supplied to make working with those XalanDOMChar*
strings easier would be helpful.


In either case, a class like this would be ok:

class XalanDOMString {
public:
    XalanDOMString(); // m_len=-1, m_pData = NULL;
    XalanDOMString( XalanDOMChar* pNullTermString );// take ownership of
this string
    XalanDOMString( const XalanDOMChar* pNullTermString );
    XalanDOMString( const XalanDOMChar* pData, long nLen );
    XalanDOMString( const XalanDOMString& );// copy constructor
    virtual XalanDOMString();

    operator = ( const XalanDOMString& );
    operator = ( const XalanDOMChar* pNullTermString );
    operator const XalanDOMChar* ();// return m_pData [inline]

    long getLength(); // return m_len

    // some other methods like substring, concat, etc.
    ...

private:
    long m_len;
    XalanDOMChar* m_pData;
};

Just thinking about all the changes I would have to make if XalanNode
members returned
something other than a const XalanDOMString& makes my head hurt... :)


----- Original Message -----
From: <Da...@lotus.com>
To: <xa...@xml.apache.org>
Sent: Thursday, March 01, 2001 02:21 PM
Subject: [Xalan-C++] Upcoming major interface changes


> I just wanted to give everyone a heads-up about changes in the XalanDOM
> interfaces.  XalanNode and its derivatives will no longer use the
> XalanDOMString class for string values -- instead we'll return and accept
> pointers to wide strings (const XalanDOMChar*).
>
> This will not affect those people using the processor as is.  It will only
> affect anyone using the XalanDOM classes to create their own
implementation
> classes.  I apologize for this major upheaval in the interfaces, but it's
> motivated by three things:
>
>    1. Distinguishing between an empty string and a "null" string.
>
>
>    2. Performance.
>
>
>    3. Alignment with Xerces.
>
>
> I'd love to hear from anyone who has any opinions on this, pro or con.
The
> plan would be to integrate these changes in the next major Xalan-C++
> release, which will probably not be for a while.
>
> Dave