Re: [xml] A generic way to add user data to nodes?

[Daniel Veillard <veillard redhat com>]

On Thu, Jan 10, 2002 at 05:44:49PM +0100, Simon Berg wrote:
> > > > > > "Daniel" == Daniel Veillard <veillard redhat com> writes:
>     Daniel>   Fighting over ? Why ? this field is left to the
>     Daniel> application for use.
>
> If I'm using a another library that uses _private (like libxslt),
> there's nowhere I can store data specific to my application in the node.
> Right?

  Right :-) 

>     Daniel>   This is an access convention. Since the field is left to
>     Daniel> the user program that convention could be followed or
>     Daniel> not. In that case why try to impose it ?
>
> This mechanism uses this field since it's the only one free.  You can
> think of it as a way for different parts of a program to coordinate
> their use of _private .

  Yes I agree, as I said before I was tempted to do something exactly like
this. I did decide though to keep this field "undefined".
Maybe time have changed and we now need it. Another example would be schemas
validation where extra informations like the type of a node would have to
be added dynamically.
  Honnestly I have my own perception of how far the community have explored
some of the code and datatypes of libxml. Some areas are still nearly
unexplored except by me. This was clearly the case for _private one year
ago when I looked at the extensibility. At that point adding such APIs 
would not have made sense because nobody except a couple of people would
have used it.

>     Daniel>   I can perfectly see case where this should NOT be
>     Daniel> done. For example _private is used for node key indexing
>     Daniel> in libxslt and a copied node should not be considered as a
>     Daniel> keyed node. User level semantic !
>
> That's why it's a callback. If you don't want copying, make it a no-op.

  It's more complex than that. Depending on the type of copy you may or 
may not want to copy some "extra attributes". For example in XInclude 
you may not want to copy type informations inherited from Schemas validation,
while you would usually want to do this for general purpose tree copy.

>     Daniel>   Unclear to me. I have considered it, and while sometimes
>     Daniel> I would like an extensible framework, I also hate
>     Daniel> over-engineering and it's unclear to me this is really
>     Daniel> needed. Anyway this would have to be pushed to a later
>     Daniel> binary incompatible revision I'm afraid.
>
> It's possible to keep binary compatibility and still let applications 
> enable this if they want to.

  No, for example if I modified libxml this way I'm pretty sure libxslt
would crash. That's what I call binary compatibility: you upgrade the lib
will the applications fails. I'm afraid this would be the case at the moment.

  I think this is yet another perfectly valid extension for libxml3,
like the possibility to dynamically load/save the DOM trough database
APIs. In both cases this is extending the static data structures with
handlers to dynamically grow the tree or the "Information Set".
  For the moment we are in API freeze, seems more and more people are
starting to use the tree API, not just the parser code. Trying to decide
now what is really required for the next steps might be premature. But
suggestions and exchanges/feedback over design are very welcome. BTW thanks
for bringing this up,

Daniel.

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/