Re: [xml] Re: [xslt] libxslt effects on _private member of libxml structures

[Sean McGuire <libxml particulate net>]

The alternative is to let _private be application-specific data, as the 
comments currently state it is, and add another field for holding the 
key() value for libxslt.  I'd prefer this, one reason being that it 
limits the changes to libxslt, rather than everyone who has used the 
_private field for their own application-specific data.  I realize this 
means more work for Daniel (sorry) but I think it's a net savings of 
work for the Whole Wide World.  On the other hand, it lacks the 
flexibility of your suggestion... but one could always hang a data 
structure like you suggest off of _private.

-Sean

Steve Ball wrote:

> Daniel Veillard wrote:
>
> > On Tue, Mar 25, 2003 at 11:47:20AM +0100, Luca Padovani wrote:
> >
> > > an hash-table maybe?
> >
> >   And libxslt is gonna do an hash-table lookup for each and
> > every node of input processed ? Nope the information that the node is
> > keyed need to go in the node itself.
>
>
> Of course not.  However, my TclDOM/libxml2 binding has also
> mis-interpreted the intent of the "_private" field and so
> is exposed to problems similar to gdome.
>
> My plan for the next major release of the Tcl binding was to
> avoid using _private altogether.  However, the thought did
> occur some time ago that perhaps there needs to be a standard
> mechanism for an application/library to hang data off a node?
> What if a Tcl script using libxml2 wanted to pass an
> xmlDoc to a gdome library (and back again)?
>
> Each application could use a hash table, but the various applications
> also want to be (time-) efficient.  Of course, providing every
> application with its own separate hook may blow-out the size of an
> xmlNode.
>
> PROPOSAL: Add a "_apphooks" field to xmlNode and xmlDoc for
> application data.  This would be a pointer to a "xmlAppHook"
> struct where applications can be allocated a per-node/per-doc
> pointer.  Each application should register itself with
> libxml2, and the xmlAppHook struct will be dynamically sized
> according to the number of applications registered.  The registration
> API would return an index into the xmlAppHook struct allocated
> to that application.
>
> Obviously applications can only register themselves at startup time.
>
> Lame attempt at ascii art:
>
> +--xmlNode--+      +----------+
> |           |      | libxslt  |
> |  _private | ---> +----------+
> |           |
> | _apphooks | ---> +-xmlAppHook-+
> |           |      |            |
> +-----------+      |  idx 0     |
>                    |            |
>                    |  idx 1     | ---> +--myData--+
>                    +------------+      |          |
>                                        | whatever |
>                                        +----------+
>
> In this case, 'xmlRegisterApplication("gdome")' returned 0
> and 'xmlRegisterApplication("tcldom")' returned 1.
> To find my data I would use nodePtr->_apphooks[1]
>
> Costs:
>
> * Adds another pointer to the xmlNode and xmlDoc structs.
> * Applications must lookup two pointers to find their data.
>   However, that's better than a hash table lookup.
> * More APIs required.
>
> Benefits:
>
> * Applications avoid clashing with libxml2, libxslt and each other.
>
> Cheers,
> Steve Ball