Re: [xml] XPath extension API

On Tue, May 15, 2001 at 01:06:37AM +0200, Thomas Broyer wrote:
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.

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.

  Agreed, I came to the same conclusion.

Functions with variable (but finite) number of arguments use the first
naming scheme with the number of arguments suffixed (xmlXPathSubstring2 and


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)


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.

  Only drawback it make more function calls ... on the other hand it will
probably make the code more compact, being nicer on the cache probably
compensates the effect. And maintenance will be easier. Okay go for it !

 · 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

  But XSLT-1.1 is dropped ...
  Okay how this will evolves in future version is still a bit unclear.
Maybe it's time to reread the XSLT 2.0 work charter. It is clear that
XPath 2.0 will merge with XQuery on the data model representation. If
someone has the cycles to do an analysis to check if we should expect
a full dynamic typing in XPath-2.0 this might save a lot of cycles in
the long run.


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml Gnome XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]