Symphony.

If I use document() to go into an external xml file and then template match some nodes from that external xml, but I want to also call some DS output that I have in my main symphony page (from where I used document()), how would I write the path to that DS output?

<xsl:apply-templates select="document('foo.xml')//kml:Document"/>
<xsl:template match="kml:Document">
... do stuff ...
<xsl:apply-templates select="/data/someDSfromSymPage"/>
</xsl:template>

Where /data/someDSfromSymPage is data from my main Symphony page and not from foo.xml

It's my first attempt with document() which I need to use in this case due to complications I can't use static DS. The data from foo.xml is working fine I just can't seem to go back up to my initial document while inside the template match.

Store your root element inside a variable and then use that when applying templates.

<xsl:variable name="data" select="/data" />

<xsl:apply-templates select="document('foo.xml')//kml:Document"/>
<xsl:template match="kml:Document">
... do stuff ...
<xsl:apply-templates select="$data/someDSfromSymPage"/>
</xsl:template>

Should work.

Yep that's working, alpacaaa to the rescue once again :)

What is the proper way to refer to the Symphony page, is it root or not? It contains my call to foo.xml, or has it become one of two roots, if so what is it that contains both?

Just out of interest.

This is a rather unintuitive aspect of xslt. When you match a node (inside a <xsl:template match />) it become your context node, meaning all your xpath expressions will be relative to it. If your context node is in another document, the context for absolute expressions would switch as well, meaning that / won't refer to the original root (as you're used to) but to the root of the document containing the node you're matching.

This sounds complicated and I am not very good at explaining these kind of things in english. Maybe someone can provide some other information :)

With stuff like that, I always found it easier to load external documents into a variable first, then I could always remember to specify the variable name first as the root.

It saves on the headache that Marco pointed out. At least it did for me ;)

I guess in my case, as solved by Marco, I've loaded my local doc into the variable.

Like many things, it makes sense when you see the solution.

I'd had a bit of hassle at first with the KML namespace in the document but I temporarily set it up as a datasource and had a look at that.

Cheers again ppl,

My God, I should read things better...

Well I think I'd prefer to load the external one into the variable for what it's worth but I'd already done the template the other way round.

So I've got the choice next time a similar situation occurs.