[Xpath-ng] My favorite XPath language

[Uche Ogbuji]

On Wed, 2002-11-20 at 18:31, David Rosenborg wrote:
> Hi all!
>  
> An excellent initiative Uche! Let's just hope it gets enough momentum.
> I'll start
> off here with some unsorted ideas and opinions just to get the
> discussion going.
>  
> If you're interested in a historical perspective you might want to
> have
> a look at FXPath (http://www.pantor.com/fxpath/) which was an
> earlier attempt
> where I tried to consolidate ideas about a successor to XPath 1.0.
>  
> To summarize my favorite XPath language I'd start with XQuery,
> remove the XML Schema stuff, use the XPath 1.0 data
> model, and add a dose of functional programming.

Certainly a very interesting approach.


> Self-sufficiency
> ------------------------------------------------------
>  
> I choose XQuery as the starting point to illustrate that I think
> that XPath Ng should be a self-sufficient language i.e., not
> dependent on a context like XSLT or XPointer. It should
> however have the capabilities to inherit properties like
> variables from a host language if present.
>  
> To be self sufficient I think XPath Ng should have constructs for 
>  
> * declaring namespaces, here you could borrow the syntax from Relax Ng
>   (as in XQuery without the 'declare' word)
>  
> * defining variables, like in XQuery: let $a := 'foo', or without the
> 'let' as in FXPath: $a := 'foo'
>  
> * defining functions. In my opinion the most powerfull option would be
> to have
>   first class function objects. This would allow for functions to be
> stored in variables
>   and passed as parameters and return values. This was suggested in my
> FXPath
>   spec and further elaborated in my own test implementation. The
> following
>   example outlines the general idea:
>  
>     $find-member := func ($struct, $name) { $struct/member [@name =
> $name] }
>     ...
>     $find-member ($some-struct, 'foo')

Interesting.  This would seem to require some multiple statement
support, moving away from the simple expression roots of XPath.  I have
no objections to this, prima facie, but I wanted to mention this fact.

I certainly agree that in-line function definitions would be very handy.

We should also then have a means of setting the context node.  Say

let . = /foo/bar

Going with my previous thought on work products, I could see 2 modules
here: a context definition module and a function definition module.


> Backward compatibility
> ------------------------------------------------------
>  
> XPath 1.0 expressions should work unmodifed when processed by an XPath
> Ng
> processor.

I really like this design principle, but I wonder whather we'll be able
to stick to it as we go on.

 
> Schema support
> ------------------------------------------------------
>  
> XPath Ng should not mandate support for any particular schema
> language.

Absolutely.
+1

> Instead
> it should provide a generic facility for tunneling auxiliary
> information from, for example,
> a schema to the XPath Ng language. Such facilities have recently been
> discussed
> on xml-dev where sugestions ranges from a single annotation ()
> function to multiple
> extensible axes.

Yes.  Two modules I'd be interested in working to hammer out quickly are
extension axes and annotations.  I think these could be the two most
broadly useful, and I also think I could churn out straw man
implementations rapidly.  We could then build a data typing module on
top of these.


> Constructors
> ------------------------------------------------------
>  
> In my opinion it wouldn't be to bad to have the so called "Computed
> Constructors"
> from XQuery available in XPath Ng. Though this might be too great of
> an overlap
> with XSLT.

Well, if XPath NG becomes self-sufficient, then I think we might as well
support output facilities, and we could borrow with reason from XQuery. 
Again, this sounds like an "output" or "constructor" module.

> List type
> ------------------------------------------------------
>  
> Instead of treating everyting as a sequnce as XPath 2.0 does, I think
> XPath Ng
> could have a separate list type and a set of functions and possibly
> primitives
> that operates on list instances.

OK.  Could lists hold any other data types besides single nodes?


> Function library import
> ------------------------------------------------------
>  
> Maybe some more advanced function library handling could be used. As
> it is now
> you'd always use prefixes for named user defined functions. It would
> be nice
> to be able to import functions for use without prefixes. Much in the
> same way
> Java package import works.

Yeah.  Given the recent arguments against qnames-in-context (some of
them good), it might be nice to have facilities for extending without
always requiring QNames.  We could set up a simple registry, for
example, for the varieties of such extensions.


> XML syntax mapping
> ------------------------------------------------------
>  
> A normative XML mapping of the XPath Ng syntax could be usefull. Just
> as there is
> an XML and compact syntax for Relax Ng, there could be two syntaxes
> for XPath Ng too,
> just that we'd use the compact form for the primary spec.

Makes eminent sense.


> That's all for now

Thanks for your thoughts.  I've had a look at FXPath before, and I'll
look again while gathering ideas.  One thing: I like your stylesheet on
http://www.pantor.com/fxpath/.  It would be a nice stylesheet for XPath
NG Web work products, subject to your agreement, general agreement, and
whether we ever produce anything that merits a stylesheet  :-)


> -- 
> Uche Ogbuji                                    Fourthought, Inc.
> http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
> Python&XML column: 2. Introducing PyXML - http://www.xml.com/pub/a/2002/09/25/py.html
> The Past, Present and Future of Web Services 1 - http://www.webservices.org/index.php/article/articleview/663/1/24/
> The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/index.php/article/articleview/679/1/24/
> Serenity through markup - http://adtmag.com/article.asp?id=6807
> Tip: Using generators for XML processing - http://www-106.ibm.com/developerworks/xml/library/x-tipgenr.html