Hi Hallvard,
I'm just wondering why you think that a custom location step is requried.
e.g. your example could be reworked a little as follows...
ext:related-thing(thing)[@color='red']
When designing the XML structure you have to anticipate the navigation
pattern, to ensure that
Hi Jan
I agree - I think the custom location step idea is just a way of reordering
an XPath statement as you say from
/ path / to / somewhere /
ext:and-now-something-completely-different( 'zz' ) /
here-we-stand
You could write
ext:and-now-something-completely-different-II(
/ path /
- Original Message -
From: Hallvard Tratteberg [EMAIL PROTECTED]
Jan,
So the same function with the same arguments
could evaluate to different things in different contexts?
There are different ways to accomplish such dynamic behavior:
- the mapping from function name to actual
James,
Although in the former case the function is called once for each node
(somewhere element) in the node set, and hence more naturally maps to
method call. In the latter case, the first argument is a node set (a set
of
somewhere Elements). Isn't that correct and doesn't that make a
- Original Message -
From: Hallvard Tratteberg [EMAIL PROTECTED]
James,
Although in the former case the function is called once for each node
(somewhere element) in the node set, and hence more naturally maps
to
method call. In the latter case, the first argument is a node set
James,
No. There is a difference between iterating over a set and
being called as a method on each object in turn. Each object
may have it's own method, like the javascript function attached to
each Element node, as in my case.
But this is an implementation detail of your model.
Well,
James,
OK lets say its specific to your model - its not part of XPath 1.0
And I won't try to push it further either. It was a fun exercise though, and
it showed me that the jaxen/saxpath code is not difficult to work with.
Tribute to the designers!
I think I'd rather leave this change for an
From: Mattias Reichel [EMAIL PROTECTED]
Hmm,
Switching to preceding axis for clarity, but issue is the same.
From Michael Kay's XSLT Programmers Reference 2nd Edition by Wrox Press,
page 364:
preceding:
This selects all the nodes that appear before the origin node, excluding
the
Ok, but it doesn't work with node() or processing-instruction() either
a
b/
?toc order-by=x?
c/
/a
c.selectSingleNode(preceding-sibling::*) returns b
c.selectSingleNode(preceding-sibling::node()) returns b
c.selectSingleNode(preceding-sibling::processing-instruction())
returns null
I've fixed that locally so it should work fine. Will be checking it in
shortly - will let you know when. I just wanted to check I'd interpreted the
spec right first.
Here's the test cases that work locally for me now - I think these look
right... Lemme know if I've missed anything
Its using
OK all my patches are now in CVS and the test cases are all working
correctly now.
James
- Original Message -
From: James Strachan [EMAIL PROTECTED]
To: Mattias Reichel [EMAIL PROTECTED]; 'bob mcwhirter'
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, April 19, 2002 1:14 PM
Right now EXML doesn't match all of the XPath unit test cases (all the other
models are fine right now). This is due to EXML trimming all whitespace. So
there's one test case that counts the number of nodes returned by an
expression, which includes Text nodes for whitespace which don't exist in
At 7:42 PM +0100 4/19/02, James Strachan wrote:
I could make the test case a bit less strict (or use non-whitespace
explicitly in the doc) - I just wondered if anyone knew how to disable
EXML's 'trim all whitespace between elements' feature.
Please don't make the test less strict. EXML is at
13 matches
Mail list logo
