[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: Language-specific output

Subject: Re: Re: Language-specific output
From: David Carlisle <davidc@xxxxxxxxx>
Date: Thu, 2 Feb 2006 13:41:33 GMT
Re:  Re: Language-specific output
> 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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.