Re: [xml] XPath extension API

[Daniel Veillard <veillard redhat com>]

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.

  okay,

> 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.

  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
> xmlXPathSubstring3)

  Okay

> 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)

  Okay

> 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

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