[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] Rewriting href


Subject: [xsl] Rewriting href
From: "Marroc" <marrocdanderfluff@xxxxxxxxxxx>
Date: Sat, 28 Jun 2008 11:22:03 +0100

Hello all, the title sounds easy but the reality is a little more tricky.

I've asked before whether an XSL 1.0 processor can 'know' the URL of the
document it is processing. The answer was NO. This time, I can be flexible
with XSLT processors and could move to 2.0 if necessary.

I have a publishing output from a CMS that creates DITA files with a choice
of href paths - relative or absolute. Both are equally problematic:
Relative:
<xref
href="../../../../Maps/foo/Content/Concepts/CW_about_installation_of_foo.dit
a.xml#*e74a6050">click here</xref>
Absolute:
<xref
href="file:/C:/PROGRA~1/FOOPRO~1/FOOPRS~1/144/146/Maps/foo/Content/Concepts/
CW_about_installation_of_foo.dita.xml#*e74a6050">click here</xref>

In this case the href is pointing to a file in the same folder as the
document being processed. 

Here are my requirements:
- I need relative paths because the DITA files are delivered zipped up for
unzipping 'who-knows-where'. 
- These relative paths shouldn't climb the directory tree ../../../../
because the downstream DITA OpenTookit processing fails, particularly for
the map (<topicref href="../Maps/..." is invalid). I'm hoping it is OK to
have '..' in the topic xrefs or <image href=... but only want as many as
necessary.
- The DOS-shortform "PROGRA~1" style paths also break downstream - I don't
know if Xalan-J can use them.
- I need to lose the bookmark but that is easy.

And a limitation:
- At the time the processing takes place, the href target may not exist.
These files are passed and processed one by one.

Can anyone suggest an XSL technique or mechanism for taking either of these
types of dysfunctional path and making them into the shortest-possible
relative path? I think this demands that the XSLT is aware of the location
of the current document so that it can parse the folder path, decide where
it varies and rebuild it in a relative fashion. 

Richard

------------------------------------------------------------ 
Richard Pineger MSc MISTC 
Technical Content Management Specialist
http://www.techdocdirect.com 


Current Thread
Keywords