Re: [xsl] Re: Language-specific output

Subject: Re: [xsl] Re: Language-specific output
From: David Carlisle <davidc@xxxxxxxxx>
Date: Thu, 2 Feb 2006 13:41:33 GMT
> So, what would you prefer? If you want to work in a totally different 
> way, how would that be?

what I (think) I'd prefer (although I have no idea if it's feasible)
would be for such a system to do essentially what I suggested to the
original poster that he do by hand: that is, to infer the missing

If you are trying to compile a module and come across an undefined
<xsl:variable name="whatever" select="/.."/>
as a global variable declaration and re-try.

At the end warn the user about this.  In XSLT1, defining a default value
of /.. is pretty much always safe, but in xslt2 this (or its cleaner
equivalent select="()" ) may generate type errors at compile time, but it's
probably the best you can do. (Unless you can get expected type
information back from saxon at the point the undefined variable was

Similarly you may have to infer named templates (and keys, etc). Again
this is easier for xslt1 as you can just make an empty template, but for
xslt2 you need to get the parameter list right before it would compile.

Of course this option
  1. One possibility is to allow the user to specify the main stylesheet 
  through some action (for instance click on a button and enter the main 
  stylesheet in a dialog).

is also good as that way you really to test in the intended
configuration rather than some automatically inferred context, but some
module stylesheets are really designed to be pulled into several
disjoint projects (which is why they are a module in the first place)
and generating an explict list of its dependancies may be more useful
than just testing in one particular project, which then might not
highlight that the module will fail to compile in a different project
due to a missing variable somewhere.

Given an explict list of variable declarations that are needed for a
project it often makes sense to just explictly add them to the file to
avoid the problem in future. If the files are being referenced by
xsl:import (rather than xsl:include) these default definitions will
typically be overwritten by higher precidence definitions in the
importing stylesheet.


This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:

Current Thread