Last night, I stumbled upon something which explains the differing
behavior between the two xpath expressions. It has to do with the
filenames of the current document and the "document()" document.
Here's the scenario:
The current file (a DITA map) is named 'b_file.xml'.
This xpath returns the left-hand expression:
ancestor::reltable|document('c_file.xml',.)//shortdesc
This xpath doesn't:
ancestor::reltable|document('a_file.xml',.)//shortdesc
a_file.xml and c_file.xml are duplicates, located in the same folder.
If the "document()" filename has a lower alphabetical ranking than the
current document, the "document()" function will always override
expression that tests the current file.
(By the way, the reason I want to return an empty node is to suppress
the shortdesc when the topicref is displayed inside a reltable.)
-----Original Message-----
From: Hussein Shafie [mailto:[email protected]]
Sent: Tuesday, March 21, 2006 2:25 AM
To: Mark Fletcher
Cc: xmleditor-support at xmlmind.com
Subject: Re: [XXE] RE: DITA configuration (Was: me again)
Mark Fletcher wrote:
>
> Thanks for the tip about using the dot as the second parameter of the
> document() function! That solved my relative path problem. FWIW, I
> can't get document() to work if there is a hash mark in the url. So I
> use this instead:
>
> document((substring-before(@conref,'#'),.)
>
> Not sure if this is as documented or not. But it's certainly an easy
> enough workaround.
At least in the XXE V3.2 (not yet released) I'm using:
* document("foo.dita#bar",.) works fine (but there must be an element
having ID "bar" in "foo.dita").
* document("foo.dita#bar/gee",.) cannot work for the reasons I've
explained in my previous email.
>
> I have another question about your xpath interpretation. I'm getting
> two different results with two similar implementations.
>
> This xpath returns the result of the expression to the left of the
pipe:
>
> xpath("ancestor::reltable|document(@href,.)//shortdesc")
>
> But this xpath never returns the result of the expression to the left
> of the pipe:
>
>
> xpath("ancestor::reltable|document(substring-before(@href,'#'),.)//*[@
> id
> =substring-after(current()/@href,'#')]/shortdesc")
>
> In fact, the left-hand expression returns false even if I do this:
>
>
> xpath(".|document(substring-before(@href,'#'),.)//*...@id=substring-afte
> r(
> current()/@href,'#')]/shortdesc")
>
>
> Is there something about my right-hand expression that's causing this?
> I've tried grouping in parentheses to make the logical distinction
> clearer, but it doesn't help.
>
I've tested a rule similar to this one:
topicref:before {
content: "*" xpath("ancestor::reltable|document(@href,.)//shortdesc");
}
And it works as expected:
* If the topicref is contained in a relcell which is contained in a
reltable, I get no generated content from the xpath() part because a
reltable and its descendants almost never contains text. (Remember how
nodesets are converted to strings.)
* If the topicref is not contained in a descendant of a reltable, this
CSS rule pulls the text of the shortdesc (if "document(@href,.)" exists
and contains at least one shortdesc).
* Note that I've added "*" to generated content because in XXE,
'content:"";' means suppress generated content.
