[XML-SIG] XPathGrammar question

[Martijn Faassen]

Martin v. Loewis wrote:
> > So now I'm trying to use it. Late last year Martin posted an IDL
> > description of a pluggable parser system, and I can also find a new
> > IDL description adding some interfaces to support XSLT. Looking at the
> > sources however I think the interfaces have evolved a bit since then;
> > is there a more up to date IDL somewhere?
> 
> I'm only aware of a single change that I made a few days ago. Since
> nobody was interested in this IDL, I lost interest as well.

I'm interested in it; it would've taken me a long time to get to
where I am now with an XPath parser, which leaves me to concentrate
on the actual semantics instead of the parsing. So, finding your
IDL in the archives made me happy. :)

> If you
> want to use it, feel free to contribute patches. If somebody else
> besides me uses it, I'm willing to stick to it even if the underlying
> 4XPath implementation changes.
> 
> In any case, the most recent revision of the IDL file carries the
> version number 1.8.

Is it in CVS somewhere?

> > However, when I try to parse the expression:
> > 
> >   //foo
> > 
> > I get the following output:
> 
> Notice that this is short for
> 
> /descendant-or-self::node()/child::foo

Okay, but feeding that into the parser gets me:

createAxisSpecifier 6
createNodeTest 4
createStep 6 4 []
createAxisSpecifier 4
createNameTest None foo
createStep 4 (None, 'foo') []
createRelativeLocationPath (6, 4, []) (4, (None, 'foo'), [])
createAbsoluteLocationPath ((6, 4, []), (4, (None, 'foo'), []))

I.e. whatever is the case, this still gives me an axis specifier of 6.
It looks quite different from the other case..

> > createAxisSpecifier 4
> > createNameTest None foo
> > createStep 4 (None, 'foo') []
> > createAbbreviatedAbsoluteLocationPath (4, (None, 'foo'), [])
> > 
> > i.e. createAxisSpecifier() gets as its 'name' argument the number 4, which
> > indicates the CHILD axis. // should get me the DESCENDANT_OR_SELF (6) axis
> > however. 
> 
> The first step created is the child::foo step, which is then used to
> create the abbreviated location path. 
> createAbbreviatedAbsoluteLocationPath has only a single argument, so
> I'm uncertain why you list it with four arguments.

That's a tuple; I let my simple factory return all its arguments as a
tuple all the time, and the parser passes them in again. I wanted to
see what the parser did with these, and as I'm exploring what's
new territory for me that seemed like a good idea. :)

> > Placing // in the middle such as with foo//bar still seems to 
> > get me child. 
> 
> Certainly, for the same reason. You should get a abbreviated relative
> location step in this case, though.

Well, but foo//bar gets me this:

createAxisSpecifier 4
createNameTest None foo
createStep 4 (None, 'foo') []
createAxisSpecifier 4
createNameTest None bar
createStep 4 (None, 'bar') []
createAbbreviatedRelativeLocationPath (4, (None, 'foo'), []) (4, (None, 'bar'), [])

And foo/descendant-or-self::node()/child::bar gets me this:

createAxisSpecifier 4
createNameTest None foo
createStep 4 (None, 'foo') []
createAxisSpecifier 6
createNodeTest 4
createStep 6 4 []
createRelativeLocationPath (4, (None, 'foo'), []) (6, 4, [])
createAxisSpecifier 4
createNameTest None bar
createStep 4 (None, 'bar') []
createRelativeLocationPath ((4, (None, 'foo'), []), (6, 4, [])) (4, (None, 'bar'), [])

It would seem to me that whatever happens the former should get a 
descendant-or-self step somewhere in there, so I still don't get it.
 
> > Shouldn't I be getting the same in both cases? Is this a bug or am I
> > missing something?
> 
> I think you are missing something. This is difficult matter, though,
> so I may as well.

I was definitely missing something, but something odd still seems to be
going on.

Thanks,

Martijn