«

I want to add a semi-static link in my RSS display page so people can
subscribe to the feed. Note: I do not have control over the RSS feed
itself, just the XSL used to transform (format) it.

I use a {link} variable to get the url of the item (article) in my XSL
file, however, I don't know how to get the url of the RSS feed itself.
Technically, it's not part of the xml data itself so I'm a little
stumped.

We have a bunch of these, so I don't want to hard-code the URL into the
XSL file.

Is there a built-in variable that retrieves the RSS feed's URL?

The desired result would look something like this:

Blog Feed Title
- First article
- Second article
- Third article
Subscribe to this feed (link to rss url)

dirvine wrote:
> Is there a built-in variable that retrieves the RSS feed's URL?

XSLT has no knowledge of RSS. Your RSS environment *may* pass that
information in as a parameter or make it available as a function call,
but you'll have to take that up with whoever wrote that software and/or
is running that server.

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden

dirvine wrote:

> I use a {link} variable to get the url of the item (article) in my XSL
> file, however, I don't know how to get the url of the RSS feed itself.
> Technically, it's not part of the xml data itself so I'm a little
> stumped.

Then you can't get it. XSLT takes one XML input document and applies an
XSLT transform (also an XML document) to it. That's pretty much your
lot - there's no useful "environment" to access properties from. You
have the document() function, but that's really just swapping one XML
input fragment for another. You can also get up to all sorts of
mischief with extension functions, but they're likely to give you a
complicated and unstable solution.

In practice you have two viable options: First is to embed all the
necessary information in the input XML document, and I mean
_everything_. For heavy-duty CMS tasks, this is usually the best
approach.

Secondly you could use a parameter in the XSL. This may be preferable
and more "lightweight" because your XSL transform engine might offer a
simple API for setting it from outside the transform before you start,
without having to re-parse / compile the stylesheet. Even if it
doesn't, it's still just an XML document -- make the <xslaram>
element easy to locate (maybe using an id attribute) and then you can
set it through an XML DOM after loading it, but before using it as a
stylesheet (watch for performance hits though).