Jonathan,

Under what you are proposing,

>  >//ename[n]
>  >=> /descendant::ename[n]
>  >
>  >//@aname[n]
>  >=> /descendant::*/attribute::aname[n]

e//@aname would not return an 'aname' attribute associated with the 'e' 
element, only those associated with descendants.

I think there are other similar concerns, with such XPaths as 
e//following-sibling::e2 and the like.

I think when Clark and DeRose proposed '//' for 
'/descendant-or-self::node()/' they did an excellent job thinking through 
the implications: in practice, it works. What you have noted about the 
behavior of the implicit position() function in the predicate is, it is 
true, non-intuitive behavior if you take shortcuts to learning XPath (and 
who doesn't?) -- but I'd be wary of changing something this basic to fix 
something without carefully looking to see what I might be breaking with my 
fix.

Cheers,
Wendell



======================================================================
Wendell Piez                            mailto:wapiez@[...].com
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
   Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list