So, let's say you have created your own xml-based markup language. You have designed the schema, you've got some xsd's to describe it, some xslt to transform it to html so your readers can view it in a browser. Just for fun, let's say your directory structure looks something like this:

/root
 /a.xml
 /b.xml
 /c.xml

In a.xml, you want to create an active link to b.xml with your <crosslink> tag. No problem, right? You just need to hardcode that path into the crosslink tag.

<crosslink target="b.xml"/>

It's easy to transform that.

<xsl:template match="crosslink">
 <A>
  <xsl:attribute name="href"><xsl:value-of select="@target"/></xsl:attribute>
  <!-- to make it easy, throw the name of the link in -->
  <xsl:value-of select="@target"/>
 </A>
</xsl:template>

Hang on. Just for kicks let's say suddenly we need to move b.xml to a different directory.

/root
 /a.xml
 /all_files_starting_with_b
  /b.xml
 /c.xml

What now? Okay, we need to go into a.xml and change the target attribute in our <crosslink> tag. Easy. But what happens when our documentation set becomes very large and there are tens and hundreds of <crosslink> tags with a target attribute pointing to b.xml? It suddenly becomes a very large universal search and replace job.

Wouldn't it be easier to create a lookup table, give b.xml an ID, and adjust the path in one place instead of many?

<root>
 <document id="the_b_document">
  <path>/root/all_files_starting_with_b/b.xml</path>
 </document>
</root>

Now the <crosslink> tag looks something more like this: <crosslink ref_id="the_b_document"/>. The xslt to transform it looks much the same, but with one big difference.

<xsl:template match="crosslink">
 <A>
  <xsl:attribute name="href">
  <!-- grab the @ref_id, pass it to lookup code and put path returned here -->
  </xsl:attribute>
 </A>
</xsl:template>

Yes, some magic to get access to the lookup table needs to happen. It can be done in xslt if you write some inline jscript functions to load up the xml file and perform lookups. If you've got an xml build system as I mentioned earlier, you can write the code to perform the lookups there.

However, there are a few gotchas here. If you go the xslt/jscript route, the lookup table will need to be loaded every single time you transform the document. If you've got users and they want to be able to run the transform regularly to preview what the final output will look like, they won't be happy when the lookup table gets very large and takes several minutes to spool off the harddrive and into memory each time. Here you could write a nice ActiveX component that caches the lookup table for them, but then they'll have to install and configure it correctly and they'll never be quite sure which version of the lookup table is loaded unless you provide them with a user interface to inspect it.

If you've got a build system, they'll have to run that build system to see what the final output will look like. You could have a simple preview xslt that doesn't try to perform lookups, but then your users won't be able to check that they've entered ID's correctly and that they resolve to the intended target.

Anyone else have any other approaches?


This posting is provided "AS IS" with no warranties, and confers no rights.