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 declarations. If you are trying to compile a module and come across an undefined variable,generate <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 declared?) 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. David ________________________________________________________________________ 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: http://www.star.net.uk ________________________________________________________________________
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Re: Language-specific out, Michael Kay | Thread | Re: [xsl] Re: Language-specific out, Wendell Piez |
RE: [xsl] Re: Language-specific out, Michael Kay | Date | Re: [xsl] Returning HTML tags from , Agnisys |
Month |