[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Eliot,
Easy bit first:
Try test="self::xindr:indirector". You're forgetting that there's an invisible child:: axis in that XPath.
Now the hard one:
On the face of it, this would seem to be impossible, since templates aren't really functions, we just use them that way to return RTFs (which some are willing to use extensions to turn back into node sets -- but not the original nodes).
No doubt Mike K. or another implementor can confirm this; no doubt also there is some design principle of the language that accounts for why you aren't allowed such resolution.
Maybe I'm being dense, but why do you conclude
Yet if they contain all the same information, using a node-set extension couldn't you query into them and find the further information you need to continue along your chain?
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Re: [xsl] Implementing XPointer Resolution With saxon:evaluate()
Subject: Re: [xsl] Implementing XPointer Resolution With saxon:evaluate() From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> Date: Tue, 13 Aug 2002 17:53:23 -0400 |
Eliot,
Easy bit first:
Also, why does this fail?:
<xsl:for-each select="$direct-result"> <xsl:choose> <xsl:when test="xindr:indirector"> <!-- Never gets here -->
When the context node is "xindr:indirector" (as returned by name())? The corresponding template match does work. Is this a subtle side effect of name-space processing?
Try test="self::xindr:indirector". You're forgetting that there's an invisible child:: axis in that XPath.
Now the hard one:
What I can't figure out is how to have the resolve-xpointer template return the actual nodes referenced, not a copy of them--is this even possible without writing an extension function that does all the address resolution? That is, I don't see a way for the value of a template to be the direct value of a select action, rather than a copy of the value.
On the face of it, this would seem to be impossible, since templates aren't really functions, we just use them that way to return RTFs (which some are willing to use extensions to turn back into node sets -- but not the original nodes).
No doubt Mike K. or another implementor can confirm this; no doubt also there is some design principle of the language that accounts for why you aren't allowed such resolution.
Maybe I'm being dense, but why do you conclude
However, my implementation of resolve-xpointer uses xsl:copy-of, which of course isn't going to work because the copy nodes are not the same as the initial target nodes.
Yet if they contain all the same information, using a node-set extension couldn't you query into them and find the further information you need to continue along your chain?
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 ======================================================================
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Implementing XPointer Res, W. Eliot Kimber | Thread | Re: [xsl] Implementing XPointer Res, W. Eliot Kimber |
Re: [xsl] Implementing XPointer Res, W. Eliot Kimber | Date | Re: [xsl] transforming XML into XML, J.Pietschmann |
Month |
Keywords