| XSL and Customization Layers | ||
|---|---|---|
 | Server Administration |  |
| XSL and Customization Layers | ||
|---|---|---|
| | Server Administration | |
If a user checks the appropriate box in the user interface, indicating that an uploaded project's XSL should be used, and if the project includes an appropriately named, appropriately located XSL file, that XSL file will be used in place of the XSL specified in the format's command array. If the XSL file does not use an <xsl:import> element, the path and filename you specify for the format's default XSL becomes irrelevant.
You cannot force users to import server-side XSL into their customization layers, as there is no requirement that a project's XSL use an <xsl:import> element. However, if a project's XSL does use an <xsl:import> element, its "href" attribute value must be the same as the value used in the second member of the format's command array.[11]
Users can choose to format XML using any of the following:
Only the XSL you specify in the format's command array — No XSL file in a project.
Just the XSL file in a project — No <xsl:import> element in a project's XSL.
An XSL customization layer that imports a format's default XSL — In the project's XSL, the <xsl:import> element's "href" attribute value must exactly match the command array's second member, which must exactly match the path and filename for the format's default XSL.
XSL in uploaded projects must meet the following requirements:
The element prefix and element name "xsl:import" must be used if the XSL uses an <import> element, as in "<xsl:import href='…'>".
Uploaded project XSL must be in a file named the same as the project's XML file, but with a ".xsl" filename extension. When formatting a project with uploaded XSL, prior to running the XSLT command, the format's default XSL path and filename are replaced with the name of the uploaded XSL file.
The XSL file must exist as a peer to the project's XML file inside the project's topmost directory.
It is possible for a user to upload and attempt to use XSL inappropriate for the command array behind the chosen formatting option. For example, a user may upload a project with XSL written for producing an FO file, but the chosen format is one that returns HTML. Or, a customization layer written for HTML may attempt to import XSL with instructions written for producing an FO file. In cases such as these, the XSL transformer is almost certain to produce an error, and the user is transferred to an error page. There is nothing you can do to prevent this type of mistake. However, the XMLP_JavaUtils applet automatically parses project XSL files and performs some checks to help prevent other mistakes. For example, if a project contains an XSL customization layer that is not well formed, or if the customization layer contains more than one <xsl:import> element, the XMLP_JavaUtils applet prevents the user from uploading the project.
Suggestions for XSL on the server include the following:
Use multiple customization layers and XSL import combinations to enforce common product family formatting and a consistent corporate image.
By providing formatting variations of a base format, each with an appropriate mix of <xsl:import> elements and its own command array, you can ensure that the same logo, fonts, heading styles, etc. are used in documents formatted as HTML Help, PDF, HTML, or any format.
Use PULL_XXX_ON_STARTUP <context-param> elements to ensure that you always deploy the most recent version of your server-side XSL.
PULL_XXX_ON_STARTUP <context-param> elements are used to pull and place XML or XSL upon startup of the servlet container. See PULL_XXX_ON_STARTUP for information on the PULL_XXX_ON_STARTUP <context-param> element.
[11] For security reasons, Mr. XML Publisher's defaults allow in users' customization layers only one <xsl:import> element. See Java Applets for information on how to change this default.
| |  | |
| Shell Scripts, Ant Scripts, Makefiles, and XProc |  | ENVIRONMENTs |