Le 15/05/01 00:19:53, Thomas Broyer a écrit : Le 14/05/01 01:23:31, Thomas Broyer a écrit :
· add functions or macros hiding node-sets internal structure, corresponding to the item() and length properties of DOM NodeList. Not necessary.
Done via macros (until functions are needed) in xpath.h (see patch):
#define xmlXPathNodeSetGetLength(ns) ((ns) ? (ns)->nodeNr : 0)
#define xmlXPathNodeSetItem(ns, index) \
(((ns) &&
((index) > 0) && ((index) <= (ns)->nodeNr)) ?
(ns)->nodeTab[(index)]
: NULL)
· 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
*/
For a functions like id(), there should be one function per possible behaviour and one function following the XPath prototype. We need to define how these functions are named for an homogeneous, unambiguous library. Suggestions: Functions following the XPath prototype use xmlXPathF, where F is the name of the function, with each word capitalized and hyphens removed (id turn into Id, string-length into StringLength). Functions wrapping the above ones for use by the XPath processors use the same name with a Function suffix (xmlXPathId become xmlXPathIdFunction). This is the current naming scheme. Functions with variable (but finite) number of arguments use the first naming scheme with the number of arguments suffixed (xmlXPathSubstring2 and xmlXPathSubstring3) Functions expecting a node-set argument and working only on the first node in document order (f.i., name()) use xmlXPathNodeF where is the same as in the first naming scheme above (xmlXPathNodeName) The only built-in function expected unbound number of arguments is concat(), xmlStrcat may be considered sufficient. I follow these rules for the EXSLT functions.
Functions called by the XPath processor would just be wrappers
managing arity checking, type casting, stack popping/pushing, etc.
This is what I'm doing for EXSLT. Code is easier to read and functions are easier to reuse.
· add functions for creating external types. An external type should reference conversion functions to basic types (Number (int), Boolean (double) and String (xmlChar*)).
Actually, XSLT 1.1 says: An external object represents an object that is not convertible to one of the four XPath data types Tom.
Attachment:
nodeset.diff
Description: Text document