Re: [xml] XPath extension API

[Thomas Broyer <tbroyer ltgt net>]

Le 13/05/01 23:50:20, Thomas Broyer a écrit :
> You (Daniel) said a few weeks ago libxml lacks a better XPath extension
> API. Here are some suggestions.

I just forgot some points:

 · add functions or macros hiding node-sets internal structure,
   corresponding to the item() and length properties of DOM NodeList.
   Not necessary.

 · built-in XPath functions should IMO be accessible without context
   and stack (when possible), just with the same prototype as defined
   by XPath.
   For example:
     /* this is an exception, we need to know the "context doc" */
     xmlXPathNodeSetPtr xmlXPathId (xmlDocPtr doc,
                                    xmlXPathNodeSetPtr ns);
     /*
      * I refactored xmlXPathIdFunction using a new function:
      * xmlXPathNodeSetPtr
      *     xmlXPathGetELementsByIds (xmlDocPtr doc, xmlChar * ids);
      * with ids being a whitespace separated list of IDs.
      * patch available soon
      */

      xmlChar * xmlXPathName (xmlXPathNodeSetPtr ns);
      xmlChar * xmlXPathNodeName (xmlNodePtr node);

      xmlChar * xmlXPathSubstring2 (xmlChar * str, double from);
      xmlChar * xmlXPathSubstring3 (xmlChar * str, double from,
                                    double to);
      xmlChar * xmlXPathTranslate (xmlChar * str, xmlChar * source,
                                   xmlChar * dest);

      double    xmlXPathSum (xmlXPathNodeSetPtr ns);
      double    xmlXPathFloor (double val);

    Functions called by the XPath processor would just be wrappers
    managing arity checking, type casting, stack popping/pushing, etc.

 · Explode the code into different modules (use an xpath/ directory):
     · compiled expression building
     · built-in functions (maybe one module with the functions listed
       above and another one for the wrappers)
     · extension hooks
     · parsing
     · evaluation
   Source compatibility could be achieved keeping the current three
   header files, just #including headers in the xpath/ directory.

 · add functions for creating external types. An external type should
   reference conversion functions to basic types (Number (int),
   Boolean (double) and String (xmlChar*)).
   If the "toNumber" or "toBoolean" function is NULL, object is first
   converted to a String using the "toString" function and then to a
   Number or Boolean using the built-in functions.
   Similar conventions should be established in the case the "toString"
   function is NULL, all conversion functions are NULL, etc.

   Each object type should have a unique "type" property. There should
   be some functions to register a new type with its conversion and
   freeing callbacks, or something similar, to avoid conflicts when
   using multiple external "modules". The type property is needed to
   differenciate objects coming from different "modules".
   Something similar to what's done in GTK+ 1.2 or GObject, though much,
   much simpler.

I hope I forget nothing this time (I'm pretty sure I do ;o)

Remember, these are just suggestions.

Tom.