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

Re: sanely ordering template imports?

Subject: Re: sanely ordering template imports?
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 06 Dec 2011 15:04:30 -0500
Re:  sanely ordering template imports?
Top-level constructs are global across all stylesheet fragments regardless of the order of import. The only time you need to worry about the order of import is when like-named top-level constructs are found in more than one fragment.

That your fragment is reporting a problem in oXygen is likely that you have not configured a validation scenario for your stylesheet fragments. You should be validating each fragment using the top-most content.xsl as the validation scenario. Then oXygen will act like an XSLT processor and find all of the globals.

I hope this helps.

. . . . . . . . . Ken

At 2011-12-06 11:04 -0800, James A. Robinson wrote:
Folks,

I've got a set of stylesheets that I originally set up with a primary
stylesheet 'content.xsl' that imported four other stylesheets:

  content.xsl
    imports common.xsl
    imports clean-entry.xsl
    imports clean-xhtml.xsl
    imports clean-source.xsl

Originally

  content.xsl had the bulk of the logic for processing the input
  content

  common.xsl had a few xsl:variable definitions set (the values of
  which are independent of the input)

  clean-*.xsl contained simple xsl:template match rules that elided or
  lightly modified the content.

Basically content.xsl would pull the content from various sources and
then kick of processing a mode that would be picked up by one of the
three clean-*.xsl stylesheets.

After this original setup had been in place for a little while I found
myself needing to add new functionality to the clean-*.xsl stylesheets
that could benefit from importing common.xsl not because of the
stylesheet but because the editor I'm using (Oxygen) would complain
about missing definitions.  Basically both clean-*.xsl and content.xsl
would be referring to variables defined in common.xsl.

I can't be the first person who has encountered this, so I'm wondering
what you all do in situations like that.  Do you simply take the hit
of redundant import statements, or do you restructure your
stylesheets?  If you do the latter, do you tend to follow a specific
set of rules on how to lay out the imports?


Jim


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
James A. Robinson                       jim.robinson@xxxxxxxxxxxx
Stanford University HighWire Press      http://highwire.stanford.edu/
+1 650 7237294 (Work)                   +1 650 7259335 (Fax)


--
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour video lecture: XSLT/XPath 1.0 & 2.0 http://ude.my/t37DVX
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal

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.