This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: XSLT & XBase ( Dans Special theory of Relativity (C) )


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]