Subject: Re: XSLT & XBase ( Dans Special theory of Relativity (C) ) From: Dan Morrison <dman@xxxxxxxx> Date: Wed, 24 May 2000 00:36:18 +1200 |
Eric van der Vlist wrote: > > [1] : http://lists.w3.org/Archives/Public/xml-uri/ Cripes, they're frothing at the mouth over there! > Imagine a use case where you are using relative URIs with the following > bases : > > ./xml/ for the document > ./xsl/ for the stylesheet > ./doc/out/ for the output tree Reading my filesystem as well as my posts are you? I guess my setup isn't that unique then :-) Without needing to imagine, I've dealt with this issue several times already just getting html hrefs and stuff to work. Haven't worried about relative namespaces yet... To illustrate my complicated arrangement (because it is messy)... <LONG_CASE_STUDY> my XML files refer to each other using relative paths. My XSL files cascade into each other using relative <xsl:include>s. My HTML output preserves the links, and adds many relative images courtesy of the XSL tranform they went through. My HTML output also includes comments defining the files that went into their creation, in some cases pointing directly at the XML. I also have a sitemap.xml file that indexes and hrefs to all files in this tree, which either gets invoked and rendered by a script somewhere under cgi-bin, or gets published into somewhere under ./docs from where it's supposed to still be linked in... Yes base would be handy, but I've done without it. Ditto server-root href="/path/path" . Unfortunately I did it by embedding meta-info in my content. (I use Perl XML::XSLT btw, but I imagine the concepts hold) At parse/publish time, I first generate a DOM of the XML. Then, using context information available to the management environment, I inject these hints into the root of my XML as follows: For the file "devnz/xml/pages/pageone.xml" ######################################## <PAGE name="pageone" suffix="xml" initial_href="devnz/" result_prefix="html/" result_path="pages/" result_suffix=".html" path="../../" template_title="Sigma DHTML GUI" > ... XML document ... </PAGE> ######################################## Those attributes all have some meaning, while I'm still in development, but I haven't defined them very well yet. :-{ Once that's out of the way, I can use the XSL processor to do the rest of the job, handing it the DOM and a (cached) stylesheet: ######################################## .... <a> <xsl:attribute name="href"> <xsl:value-of select="/PAGE/@name"/> _print <xsl:value-of select="/PAGE/@result_suffix"/> </xsl:attribute> Printable Page <img> <xsl:attribute name="src"><xsl:value-of select="/PAGE/@path"/>images/printer.gif</xsl:attribute> </a> .... ######################################## This is a _simplified_ example! What it does is define for the published html page, which will end up living in "./html/pages/pageone.html", that it can find a file called "pageone_print.html" nearby. Every one of those attributes is a parameter that is to be manipulated by the publishing environment. I'm not even assuming suffix="html", as one admin setting can change that completely. Anyway, although this approach does rely on the server environment being clever, I've tried to pull as much of the smarts out into the open and into the XSL. I see it as trivial to port the attribute injecting trick to another platform. The XML can actually be safely stored retaining this info (tho' I wouldn't reccommend it), it degrades fairly unobtrusively, and you don't have to go nuts with string-manipulation in XSL (shudder). (Yay Perl) It works for me, although explaining why could be a drag. Bonus is that I can move "devnz/xml/pages/pageone.xml" into "devnz/xml/pages/chapterone/pageone.xml" and ALL THE LINKS HOLD! I realise this approach is so bizarre as make a few purists wince (if they take the time to analyse it) but it's my commitment to keeping the structural code in one place - the XSL - that's paying off. I can write a one-page VBscript that would port my entire site to client-side IE5 now, no server intervention, without changing my sources. <sulk>... And all because I wasn't allowed to use <XML:base/></sulk> </LONG_CASE_STUDY> Phew. Well Eric, your well-researched posting deserved a bit of effort in response. Anyone got any response to my horrid approach outlined above? Or should I patent it yesterday? (I can you know, I'm in New Zealand!) .dan. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
XSLT & XBase, Eric van der Vlist | Thread | Re: XSLT & XBase ( Dans Special the, Eric van der Vlist |
template conflicts, Linda van den Brink | Date | Re: Number of node in list from sty, David Carlisle |
Month |