Re: [xsl] // expanding to descendant-or-self::node()

[Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>]

Andrew,

At 09:47 AM 9/16/2008, you wrote:
> > currently // expands to /descendant-or-self::node()/ which is not owhat
> > one would first think of, but it works consistently without depending on
> > the following step. And that expansion is at the level of expression
> > terms not syntax fragments.
> >
> > one might expect // to expand to descendant::  but descendant:: itself
> > isn't really an expression, just part of the syntax for an axis step and
> > that causes problems..
> >
> > //foo could have been defined to be /descendant::foo
> > but you can not define
> > //@foo to be descendant::@foo as that's a syntax error, wheras
> >  /descendant-or-self::node()/@foo is all foo attributes in the document,
> > which is the desired meaning.
> >
> > similarly any other axis, including child::
> > //child::foo can't expand to /descendant::child::foo
>
> //@foo and //child:: would both be errors -  //@* would need to be
> //*/@foo and //child:: doesn't make sense anyway
>
> I think that's a better situation than we have now...

As Michael Sperberg-McQueen said this year at Balisage, "no spec 
written without the benefit of clairvoyance is perfect", which I 
think is too cautious a generalization, as I haven't seen any perfect 
ones even whose authors have assured me they were clairvoyant (or who 
have at least held themselves to that standard).

I agree that with the benefit of hindsight, it appears the 
specification of "//" is slightly too elegantly contrived to achieve 
the desired effect without incident (thus showing again how too 
elegant is hardly elegant at all). The XPath 1.0 spec could perhaps 
have been only somewhat more complex, along lines you suggest, and 
avoided the gotcha.

But what other gotchas would that complexity have introduced? Until 
we have thousands of users banging on it every day, we probably won't know.

As it is, we have a technology that works straightforwardly most of 
the time even when you fake it, and all of the time if you can make 
the effort to learn how not to. XPath is really an amazing design; we 
shouldn't be surprised if it has a blemish.

Cheers,
Wendell



======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
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
======================================================================