XML

Web.xml
 context-param Element
 The optional context-param element declares a Web Application's servlet context initialization parameters. You set each context-param within a single context-
param element, using <param-name> and <param-value> elements. You can access these parameters in your code using the
javax.servlet.ServletContext.getInitParameter() and javax.servlet.ServletContext.getInitParameterNames() methods.
 The following table describes the elements you can define within a context-param element.
 ElementRequired/
OptionalDescription<param-name>RequiredThe name of a parameter.<param-value>RequiredThe value of a parameter.<description>OptionalA text
description of a parameter.

 filter Element
 The filter element defines a filter class and its initialization parameters. For more information on filters, see Configuring Filters.
 The following table describes the elements you can define within a servlet element.
 ElementRequired/
OptionalDescription<icon>OptionalSpecifies the location within the Web Application for a small and large image used to represent the filter in a GUI tool.
Contains a small-icon and large-icon element.Currently, this element is not used by WebLogic Server.<filter-name>RequiredDefines the name of the filter,
used to reference the filter definition elsewhere in the deployment descriptor. <display-name>OptionalA short name intended to be displayed by GUI
tools.<description>OptionalA text description of the filter.<filter-class>Required The fully-qualified class name of the filter. <init-param>OptionalContains a
name/value pair as an initialization parameter of the filter.Use a separate set of <init-param> tags for each parameter.

 filter-mapping Element
 The following table describes the elements you can define within a filter-mapping element.
 ElementRequired/
OptionalDescription<filter-name>Required The name of the filter to which you are mapping a URL pattern or servlet. This name corresponds to the name
assigned in the <filter> element with the <filter-name> element.<url-pattern>Required - or map by <servlet>Describes a pattern used to resolve URLs. The
portion of the URL after the http://host:port + ContextPath is compared to the <url-pattern> by WebLogic Server. If the patterns match, the filter mapped in this
element is called.Example patterns: /soda/grape/*
/foo/*
/contents
*.fooThe URL must follow the rules specified in Section 10 of the Servlet 2.2 Specification.<servlet>Required - or map by <url-pattern>The name of a servlet
which, if called, causes this filter to execute.

 listener Element
 Define an application listener using the listener element.
 ElementRequired/
OptionalDescription<listener-class>OptionalName of the class that responds to a Web Application event.
 For more information, see Configuring an Event Listener.

 servlet Element
 The servlet element contains the declarative data of a servlet.
 If a jsp-file is specified and the <load-on-startup> element is present, then the JSP is precompiled and loaded when WebLogic Server starts.
Web.xml
 init-param Element
 This is an element within the servlet Element.
 The optional init-param element contains a name/value pair as an initialization parameter of the servlet. Use a separate set of init-param tags for each
parameter.
 You can access these parameters with the javax.servlet.ServletConfig.getInitParameter() method.
 The following table describes the elements you can define within a init-param element.
 ElementRequired/
OptionalDescription<param-name>Required Defines the name of this parameter.<param-value>Required Defines a String value for this
parameter.<description>OptionalText description of the initialization parameter.
 WebLogic Server recognizes the special initialization parameter, wl-dispatch-policy, to assign a servlet or JSP to an available execute queue. For example, the
following example assigns a servlet to use the execute threads available in an execute queue named CriticalWebApp:
 <servlet> ... <init-param> <param-name>wl-dispatch-policy</param-name> <param-value>CriticalWebApp</param-value> </init-param>
</servlet> If the CriticalWebApp queue is not available, the servlet will use execute threads available in the default WebLogic Server execute queue. See
Setting Thread Count for more information about configuring execute threads in WebLogic Server. See Using Execute Queues to Control Thread Usage for
more information about creating and using queues.
 security-role-ref Element
 This is an element within the servlet Element.
 The security-role-ref element links a security role name defined by <security-role> to an alternative role name that is hard-coded in the servlet logic. This extra
layer of abstraction allows the servlet to be configured at deployment without changing servlet code.
 The following table describes the elements you can define within a security-role-ref element.
 ElementRequired/
OptionalDescription<description>OptionalText description of the role.<role-name>Required Defines the name of the security role or principal that is used in
the servlet code.<role-link>Required Defines the name of the security role that is defined in a <security-role> element later in the deployment descriptor.

 servlet-mapping Element
 The servlet-mapping element defines a mapping between a servlet and a URL pattern.
 The following table describes the elements you can define within a servlet-mapping element.
 ElementRequired/
OptionalDescription<servlet-name>Required The name of the servlet to which you are mapping a URL pattern. This name corresponds to the name you
assigned a servlet in a <servlet> declaration tag.<url-pattern>Required Describes a pattern used to resolve URLs. The portion of the URL after the
http://host:port + WebAppName is compared to the <url-pattern> by WebLogic Server. If the patterns match, the servlet mapped in this element will be
called.Example patterns: /soda/grape/*
/foo/*
/contents
*.fooThe URL must follow the rules specified in Section 10 of the Servlet 2.2 Specification.For additional examples of servlet mapping, see Servlet Mapping.

 session-config Element
 The session-config element defines the session parameters for this Web Application.
 The following table describes the element you can define within a session-config element.
 ElementRequired/
web.xml

 welcome-file-list Element
 The optional welcome-file-list element contains an ordered list of welcome-file elements.
 When the URL request is a directory name, WebLogic Server serves the first file specified in this element. If that file is not found, the server then tries the next
file in the list.
 For more information, see Configuring Welcome Pages and How WebLogic Server Resolves HTTP Requests.
 The following table describes the element you can define within a welcome-file-list element.
 ElementRequired/
OptionalDescription<welcome-file>OptionalFile name to use as a default welcome file, such as index.html

 error-page Element
 The optional error-page element specifies a mapping between an error code or exception type to the path of a resource in the Web Application.
 When an error occurs—while WebLogic Server is responding to an HTTP request, or as a result of a Java exception—WebLogic Server returns an HTML
page that displays either the HTTP error code or a page containing the Java error message. You can define your own HTML page to be displayed in place of
these default error pages or in response to a Java exception.
 For more information, see Customizing HTTP Error Responses and How WebLogic Server Resolves HTTP Requests.
 The following table describes the elements you can define within an error-page element.
 Note: Define either an <error-code> or an <exception-type> but not both.
 ElementRequired/
OptionalDescription<error-code>Optional A valid HTTP error code, for example, 404.<exception-type>OptionalA fully-qualified class name of a Java
exception type, for example, java.lang.string<location>Required The location of the resource to display in response to the error. For example, /myErrorPg.html.

 taglib Element
 The optional taglib element describes a JSP tag library.
 This element associates the location of a JSP Tag Library Descriptor (TLD) with a URI pattern. Although you can specify a TLD in your JSP that is relative to
the WEB-INF directory, you can also use the <taglib> tag to configure the TLD when deploying your Web Application. Use a separate element for each TLD.
 The following table describes the elements you can define within a taglib element.
 ElementRequired/
OptionalDescription<taglib-location>Required Gives the file name of the tag library descriptor relative to the root of the Web Application. It is a good idea to
store the tag library descriptor file under the WEB-INF directory so it is not publicly available over an HTTP request. <taglib-uri>Required Describes a URI,
relative to the location of the web.xml document, identifying a Tag Library used in the Web Application.If the URI matches the URI string used in the taglib
directive on the JSP page, this taglib is used.
Web.xml
 ejb-ref Element
 The optional ejb-ref element defines a reference to an EJB resource. This reference is
mapped to the actual location of the EJB at deployment time by defining the mapping in
the WebLogic-specific deployment descriptor file, weblogic.xml. Use a separate <ejb-ref>
element to define each reference EJB name.
 The following table describes the elements you can define within an ejb-ref element.
 ElementRequired/
OptionalDescription<description>OptionalA text description of the reference.<ejb-ref-
name>Required The name of the EJB used in the Web Application. This name is mapped
to the JNDI tree in the WebLogic-specific deployment descriptor weblogic.xml. For more
information, see ejb-reference-description Element.<ejb-ref-type>Required The expected
Java class type of the referenced EJB.<home>Required The fully qualified class name of
the EJB home interface.<remote>Required The fully qualified class name of the EJB
remote interface.<ejb-link>OptionalThe <ejb-name> of an EJB in an encompassing J2EE
application package.<run-as>OptionalA security role whose security context is applied to
the referenced EJB. Must be a security role defined with the <security-role> element.
 XML– eXtensible Markup Language
 ◆ Open standard
 ◆ Any kind of data
 ◆ Unicode character set
 ◆ Clear syntax
 ◆ Unambiguous structure
 What XML is NOT
 ◆ A replacement for HTML
 ◆ A programming language
 ◆ A network transport protocol
 ◆ A database
 XML
◆ A language for creating markup languages
 ◆ Resembles HTML or SGML
 ◆ Tags, attributes and values
 ◆ DTD's
 ◆ Portable data
 A sample XML file
 <?xml version="1.0" ?>
 <course>
 <name>Doc. Proc. Lang.</name>
 <number>2081-742</number>
 <instructor>C.R. Myers</instructor>
 <time>Tuesday, Noon - 2PM</time>
 <time>Thursday, Noon - 2PM</time>
 </course>
XML entities
◆ less than = &lt; (<)
◆ greater than = &gt; (>)
◆ quotation mark = &quot; (")
◆ apostrophe = &apos; (')
◆ ampersand = &amp; (&)
 XML syntax rules
 ◆ Tags are case sensitive
 ◆ Each document must have a root
 ◆ Closing tags are required
 ◆ Values must be enclosed in quotation
marks
 ◆ Elements must be properly nested
 ◆ Entities must be declared
 Tags are case-sensitive
 <CourseName> is different from
<coursename>
 <Bad>This is bad XML</bad>
 XML documents must have a root
 <root>
 <child>
 <subchild>
 </subchild>
 </child>
 </root>
 Closing tags are required
 This is bad XML<p>
 This is also bad<br>
 <p>This is ok</p>
 This is the shortcut for an empty tag<br/>
 Values must be in quotation marks
 <student id=1234>Bad Student!</student>
 <student id="1234">Good Student</student>
 Elements must be properly nested
 <tag1><tag2>Badly nested!</tag1></tag2>
 <tag1><tag2>Looks good!</tag2></tag1>
 Attributesvs. Elements
 Using an Element for gender:
 <person>
 <gender>female</gender>
 <firstname>Jane</firstname>
 <lastname>Doe<lastname>
 </person>
 Attributesvs. Elements
 Using an Attribute for gender:
 <person gender="female">
 <firstname>Jane</firstname>
 <lastname>Doe<lastname>
 </person>
 Attributedisadvantages
 ◆ Can't contain multiple values
 ◆ Not very expandable
 ◆ Can't describe structures
 ◆ More difficult to manipulate
 ◆ Hard to test against a DTD
 Attributesstill useful
 ◆ Great for internal info, not needed by the
user
 <messages>
 <note id="123">Blah, blah, blah.</note>
 <note id="124">More boring stuff</note>
 </messages>
 Types of XML documents
 ◆ Well-formed
 ◆ Valid
 ◆ Invalid
 "Well-formed" XML
 ◆ Follows the XML syntax rules
 <?xml version="1.0"?>
 <course>
 <name>Document Processing Languages</name>
 <number>2081-742</number>
 <college>CIAS</college>
 <credits>4</credits>
 <desc>Grad publishing technology</desc>
 </course>
 "Valid" XML
 ◆ A well-formed XML doc that conforms to a DTD
 <?xml version="1.0"?>
 <!DOCTYPE course SYSTEM "courses.dtd">
 <course>
 <name>Document Processing Languages</name>
 <number>2081-742</number>
 <college>CIAS</college>
 <credits>4</credits>
 <desc>Grad publishing technology</desc>
 </course>
 An XML Example
 ◆ We will define a person like this:
 ◆ A person is required to be either male or female
 ◆ A person has a name which consists of:
 ◆ A first name
 ◆ A last name
 ◆ One (optional) nickname
 ◆ A person has an occupation
 ◆ A person has a description
 An XML Example
 ◆ We will define a person like this:
 <person gender=“male”>
 <name>
 <first>Charles</first>
 <last>Myers</last>
 <nickname>C.R.</nickname>
 </name>
 <occupation>college professor</occupation>
 <description>bald geek</description>
 </person>
 The “person” DTD
 <!ELEMENT person (name, occupation, description)>
 <!ELEMENT name (first, last, nickname?)>
 <!ELEMENT first (#PCDATA)>
 <!ELEMENT last (#PCDATA)>
 <!ELEMENT nickname (#PCDATA)>
 <!ELEMENT occupation (#PCDATA)>
 <!ELEMENT description (#PCDATA)>
 <!ATTRIBUTE person gender (male | female) #REQUIRED>
 What'swrong with DTD's
 ◆ DTD’s use old SGML style definitions
 ◆ DTD are not written in XML
 XML Schema
 ◆ XML definition system developed to
replace
 Document Type Definitions
 Other related technologies
 ◆ CSS - Cascading Style Sheets for display
 ◆ XSL - Extensible Stylesheet Language for display
 ◆ XSLT - XSL Transformations
 ◆ Xpath - Allows XML files to include other content
 ◆ Xlink - Allows XML files to link to other XML files
 ◆ Xquery - Allows XML files to query databases
 Transforming XML
 ◆ XSLT
 ◆ Extensible Stylesheet Language - Transformations
 ◆ Can convert XML to other languages
 ◆ SGML
 ◆ HTML
 ◆ PDF
 ◆ PostScript
 ◆ Just about anything else
Struts config
 Overview

 The struts-config.xml configuration file is a link between the View and Model components in the Web Client. It plays an important role in building both
Controller components and Application-specific configurations. In Web NMS, this file is created specific to every application in the format as <module>-struts-
config.xml, where <module> can be topo, fault, perf and so on. For example, a struts-config.xml file of the fault module is represented as fault-struts-
config.xml and is present in <Web NMS Home>/webclient/fault/conf directory.

 Configuration File Structure
 The configuration file basically contains three main elements:
 <form-beans>
 <global-forwards>
 <action-mappings>
 The elements of the <module>-struts-config.xml file and their usage are described for an example module such as "fault".

 ElementAttributes and Descriptionstruts-config Is the root node of the configuration file. form-beans Contains form bean definitions. The Form beans create
ActionForm instances at runtime. The details of each form bean are provided in the <form-bean> element. The <form-property> elements within the form
bean contain the property names and the property types of the form bean. Attributes of <form-bean> are:
 name: Must have a unique bean name. This name is used as reference in the action mappings. Often, this is also the name of the request or the session
attribute under which the form is stored.
 type: The value is a fully-qualified classname of the ActionForm class used with the form bean.
 Attributes of <form-property> are:
 name: Contains the name of a property of the form bean.
 type: Contains the property type such as String, String[], etc.
 Example Entry <form-bean name="EventCVForm" type="org.apache.struts.validator.DynaValidatorForm"> <form-property name="cvName"
type="java.lang.String"/> <form-property name="severity" type="java.lang.String[]"/> ......</form-bean> global forwardsContains the global forward definitions.
The forward name is the logical name used to map to a specific JSP. The logical name mappings for commonly used presentation pages are specified here.
The <forward> element contains the logical name and the name of the corresponding resource which it maps to. Attributes of <forward> are:
 name: Contains the logical name of the forward. This name is used in the ActionForm class's execute() method to forward it to the next resource. Example:
MyTestPage
 path: Contains the context relative path of the resource to which the forward name maps. Example: /TestPage.jsp [or] /TestPage.do
 contextRelative:This takes the value true or false implying, whether the resource specified in the path attribute is relative to the context.
 Example Entry <forward name="viewAlarm" path="/fault/AlarmView.do" contextRelative="true"/> In the above entry, wherever this file is to be called, only
viewAlarm is specified. This allows you to change the Alarm View page without changing the references to it throughout the Web Client. The action mapping
for the AlarmView.do is defined in the action mapping, where it is forwarded to the next appropriate resource. action-mappingsContains the action definitions.
Each action mapping is defined in an <action> element. The <forward> definition within <action>, maps the result of the action to the jsp page invoked. This
is a 'local' forward and is optional. That is, for the particular request object, if there is no forward defined in the global forwards, it is specified in the <action-
mapping> element.
Attributes of <action-mappings> are:
 path: Contains the name of the request received
 Overview

 This topic deals with certain configurations handled by the web.xml file located in <Web NMS Home>/WEB-INF directory and provides links to navigate to
other related topics for customizing Web Client.

 Several Web Client customizations are performed by configuring the parameters of the web.xml file located in <Web NMS Home>/WEB-INF directory. Some
of these parameters are optional and can be used as per your requirement. web.xml is created by concatenating web-header.xml, web1.xml, and web-
footer.xml i.e., web.xml = web-header.xml + web1.xml + web-footer.xml. If you make any configuration in web.xml, then it will be over-written when you run
compileJSP.bat/sh tool (from <Web NMS Home>/bin directory) for compiling the jsp files.
The file web1.xml is a temporary file created when the compileJSP.bat/sh tool is run. Once the web.xml is created, this file is removed.

 For example,if you have made any configurations in web.xml, you must configure the same parameters in the web-header.xml file too located in <Web NMS
Home>/WEB-INF directory. This is so, because the entries of the web.xml file is overwritten while compiling the JSP files. Entry of your configurations in the
web-header.xml file will restore the configurable entries into the web.xml file during compilation.

 Configurable Items

 The list of configurable items for Web Client are given below,

 Display of Page Loading Time

 It is possible to configure the display of loading time of a page in the Web Client. The optional parameter namely "showPageLoadingTime" can be used to
configure whether the loading time is to be displayed or not. This parameter takes "true" or "false" as values. If the value is "true" then the loading time is
displayed above the status bar of the client. If the value is "false" or if no value is specified then the loading time of the page is not displayed. The entry of this
parameter in web.xml file is as shown below:

 <context-param> <param-name>showPageLoadingTime</param-name> <param-value>true</param-value> </context-param>
 Modify the Default Skin

 The default skin for the Web Client is one which is displayed at client startup. Either of the available skins such as "olive green" and "steel blue" can be set as
the default skin. The parameter for setting the default skin is "defaultSkin" and its entry is given in the web.xml file as shown below:

 <context-param> <param-name>defaultSkin</param-name> <param-value>SteelBlue</param-value> </context-param>

 Configuring Meter Chart

 In the properties page for SNMP nodes, Meter charts and Pie graphs are displayed for CPU Utilization, Memory Utilization and Disk Utilization. By default, the
device is queried to show the latest values. An option to query the database instead of a direct device query is also provided. This can be configured in
What’s wrong with HTML?

 Simple, but not powerful

 Tags pre-defined
 Not strict about syntax
 Tags are formatting oriented
 Extensible Markup Language (XML) is a general-purpose
markup language.[1] It is classified as an extensible language
because it allows its users to define their own tags. Its primary
purpose is to facilitate the sharing of structured data across
different information systems, particularly via the Internet.[2]
Thus its usage encompasses both the document encoding
arena and the data serialization arena. By adding semantic
constraints, application languages can be implemented in XML.
These include XHTML,[3] RSS, MathML, GraphML,
Scalable Vector Graphics, MusicXML, and thousands of others.
Moreover, XML is sometimes used as the
specification language for such application languages.
 XML is recommended by the World Wide Web Consortium. It is
a fee-free open standard. Well-formed and valid XML
documents
 There are two levels of correctness of an XML document:
 Well-formed. A well-formed document conforms to all of XML's
syntax rules. For example, if an element has an opening tag
with no closing tag and is not self-closing, it is not well-formed.
A document that is not well-formed is not considered to be
XML; a conforming parser is not allowed to process it.
 Valid. A valid document additionally conforms to some
semantic rules. These rules are either user-defined, or included
as an XML schema or DTD. For example, if a document
contains an undefined tag, then it is not valid; a validating
parser is not allowed to process it.
A method of creating and using tags to
identify the structure and contents of a
document — not how it should be displayed
 The tags used can be arbitrary or can come
from a specification
Sample xml document
 <?xml version="1.0"?>
 <book>
 <author>
 <lastname>Tennant</lastname>
 <firstname>Roy</lastname>
 </author>
 <title>The Great American Novel</title>
 <chapter number=“1”>
 <chaptitle>It Was Dark and Stormy</chaptitle>
 <p> “I’m scared,” I said.</p>
 </chapter>
 </book>
Ways to Use XML

 Behind the scenes as a standard and easily

transformed format for information
 As a transfer syntax, to exchange information
in a machine-parseable form
 As a method of delivery direct to the user
Why is XML Important?

 Itis a standard, easily extensible way to

encode loosely-structured as well as highly-
structured information
 Due to its easy parseability, software can
transform it in countless ways, thereby
allowing:
– Easy migration paths
– Alternative displays
– On-the-fly response to user needs
Serving XML to the Web

 Directlyin native form

 Transformed to static HTML
 Transformed to HTML dynamically
Transforming XML: XSLT

 XML Stylesheet Language — Transformations

(XSLT)
 A markup language and programming syntax for
processing XML
 Is most often used to:
– Transform XML to HTML for delivery to standard web
clients
– Transform XML from one set of XML tags to
another
– Transform XML into another syntax/system
Required Components for
Serving XML to the Web

 An XML-encoded “document”
 An XSLT stylesheet to…
 …transform it to HTML or XHTML:
– Static
– Dynamic
A CSS stylesheet (optional)
Key XML Capabilities

 XML can be used to define or represent

structure in all kinds of data
 XML is a medium for data integration
 XML has a set of related technologies for
processing XML tagged data
 XML separates content from presentation
 XML is the common language for data
interchange
Advantages

 XML is a standard format for defining structure in all

kinds of data
 XML is a medium for data interchange
 XML has a developing set of related technologies for
managing XML tagged data
– XSL/T, XPath, XLink, XPointer, XQuery etc.
 XML separates Content from presentation
 XML is the Lingua Franca for data interchange
Advantages

– Standard format for structuring data

– Suitable for representing all kinds of content
– XML Layer unties data from repository for data
integration
– Separates content from presentation for
customizable user interface
– Supported by growing body of open-standards
functionality
– Lingua franca for data interchange
XML for
Libraries

Roy Tennant
eScholarship
California Digital Library
escholarship.cdlib.org
Introduction

 Goal: introduce you to XML, explain what it

can do in general terms, and highlight
particular uses
 Caveat: you will not learn enough to do it
without further study
Outline

 Introductionto XML
 Serving XML to the Web
 Case Studies
 Tips & Advice
 Resources
 Introduction to XML
 Extensible Markup Language
 A method of creating and using tags to
identify the structure and contents of a
document — not how it should be displayed
 The tags used can be arbitrary or can come
from a specification
 What it Looks Like
<?xml version="1.0"?>
<book>
<author>
     <lastname>Tennant</lastname>
     <firstname>Roy</lastname>
</author>
<title>The Great American Novel</title>
<chapter number=“1”>
     <chaptitle>It Was Dark and Stormy</chaptitle>
     <p> “I’m scared,” I said.</p>
</chapter>
</book>
Two Types of XML

 Well-Formed
 Valid
Well-Formed XML
 Follows general tagging rules:
– All tags begin and end
 But can be minimized if empty: <br/> instead of <br></br>
– All tags are lowercase
– All tags are properly nested:
 <author> <firstname>Mark</firstname>
<lastname>Twain</lastname> </author>
– All attribute values are quoted:
 <subject scheme=“LCSH”>Music</subject>
 Has identification & declaration tags
 Software can make sure a
document follows these rules
 Valid XML
 Uses only specific tags and rules as codified by one
of:
– A document type definition (DTD)
– A schema definition
 Only the tags listed by the schema or DTD can be
used
 Software can take a DTD or schema and verify that
a document adheres to the rules
 Editing software can prevent an author
from using anything except allowed tags
 Ways to Use XML
 Behind the scenes as a standard and easily
transformed format for information
 As a transfer syntax, to exchange information
in a machine-parseable form
 As a method of delivery direct to the user (not
recommended)
Why is XML Important?
 It is a standard, easily extensible way to encode
loosely-structured as well as highly-structured
information
 Due to its easy parseability, software can transform it
in countless ways, thereby allowing:
– Easy migration paths
– Alternative displays
– On-the-fly response to user needs
XML vs. Databases
(a simplistic formula)

 If your information is…

– Tightly structured
– Fixed field length
– Massive numbers of individual items
 You need a database
 If your information is…
– Loosely structured
– Variable field length
– Massive record size
 You need XML
Serving XML to the Web

 Directlyin native form

 Transformed to static HTML
 Transformed to HTML dynamically
Transforming XML: XSLT
 XML Stylesheet Language — Transformations (XSLT)
 A markup language and programming syntax for
processing XML
 Is most often used to:
– Transform XML to HTML for delivery to standard web clients
– Transform XML from one set of XML tags to
another
– Transform XML into another syntax/system
Required Components for
Serving XML to the Web
 An XML-encoded “document”
 An XSLT stylesheet to…
 …transform it to HTML or XHTML:
– Static
– Dynamic
A CSS stylesheet (optional)
XML Web Publishing Software

 Required to:
– Apply dynamic transformations to XML content
– Render HTML dynamically for standard web
browsers
 Just beginning to be available:
– Cocoon: http://xml.apache.org/cocoon/
– AxKit: http://axkit.org/
 Case Study: Publishing Books @ the
California Digital Library
 Goals:
– To create highly usable online versions of books
– To create versions that will migrate easily as
technology changes
– To create an infrastructure that will
support dynamic presentations of the
same content
Case Study: Publishing Books @ the
California Digital Library

 Strategy:
 Markup the texts in XML
 Serve them dynamically using XML web publishing software
(currently Cocoon)
 Create different displays for different purposes, and a
mechanism for allowing the user to select their preferred
view
 Find and apply an XML-aware search engine
– Create a method by which users can create their own
Adobe Acrobat versions
 AxKit

mod_perl

Web Server
 Cocoon

Tomcat

Web Server
 Cocoon

Tomcat

Web Server

I want this XML doc…
 XSLT
Stylesheet

XML
Doc
Cocoon

Tomcat

Web Server
 XSLT
Stylesheet

XML
Doc XHTML
Cocoon Document
(no display
markup)*
Tomcat

HTML
Web Server Stylesheet
(CSS)

* Dynamic document
 Transformation

Information XSLT
Stylesheet Presentation

XML
Doc XHTML
Cocoon Document
(no display
markup)*
Tomcat

HTML
Web Server Stylesheet
(CSS)

* Dynamic document
Case Study: ILL ASAP
ILL
ASAP Local
Catalog
OCLC

Downloaded Internet
Requests XML File Explorer

XSL Printable
Stylesheet XHTML
File
Service Tasmania Architecture
Case Study: Univ. of Michigan
Tips and Advice
 Begin transitioning to XML now:
– XHTML and CSS for web files, XML for static documents
with long-term worth
 Do not rely on browser support of XML
 DTDs? We don’t need no stinkin’ DTDs!
 Get on the XML4Lib discussion list:
http://sunsite.berkeley.edu/XML4Lib/
 Buy my book!
Resources

 Web sites
 Electronic discussions
 Books
 Magazines and journals
 Individuals
Native XML Databases : Why
Bother?

Kimbro Staken
The dbXML Group
http://www.dbxml.com
The dbXML Open Source Project
http://www.dbxml.org
What is a Native XML Database
a) Defines a (logical) model for an XML document -- as opposed to the
data in that document -- and stores and retrieves documents according to
that model. At a minimum, the model must include elements, attributes,
PCDATA, and document order. Examples of such models are the XPath
data
model, the XML Infoset, and the models implied by the DOM and the events
in SAX 1.0.

b) Has an XML document as its fundamental unit of (logical) storage,

just as a relational database has a row in a table as its fundamental
unit of (logical) storage.

c) Is not required to have any particular underlying physical storage

model. For example, it can be built on a relational, hierarchical, or
object-oriented database, or use a proprietary storage format such as
indexed, compressed files.
Why Native XML Databases

• Straightforward storage of XML

• XML oriented query facilities
• Semi-structured data
• Easier construction of loosely coupled
applications
• Tremendous flexibility and capability for
change
• Not a replacement for RDBMS
The Problem with RDBMS and XML
• Mapping is complex and cumbersome
• With complex schemas mapping will be very
slow
• Mapping will lose structural meta-data
• Documents can not be round-tripped
• Data must be highly structured
• Can't support documents with mixed content
• Limited flexibility
Different Types of Native XML
Databases
• Custom native storage
• Software AG Tamino http://www.softwareag.com
• dbXML http://www.dbxml.org (Open Source)
• XYZFind http://www.xyzfind.com
• Built on top of object database
• Excelon http://www.exceloncorp.com
• X-Hive http://www.xhive.com
• Ozone http://www.ozone-db.org (Open Source)
• Built on top of relational database
• B-Bop Xfinity http://www.b-bop.com
How Do You Query

• W3C XPath
• Most common language currently used
• W3C XQuery
• Recommendation expected mid 2002
• Proprietary Languages
• Over time these will go away
Querying with XPath
• Simple yet powerful path based XML query
language
• /root/node[criteria = 'value']
• Many products extend XPath to allow queries
across collections of documents
• Limited in many ways
• No grouping
• No sorting
• Limited data typing
Querying with XQuery

• Builds on top of XPath and XML Schema

data types
• Enables full data-typing
• Allows joins between XML documents
• Allows sorting and grouping
• Language is SQL like but works on trees
rather then tables
• Currently in working draft status
XQuery Syntax Example

<results>
{
FOR $b IN document("http://www.bn.com")/bib/book,
$t IN $b/title,
$a IN $b/author
RETURN
<result>
{ $t }
{ $a }
</result>
}
</results>
 How do you Update Data

• W3C DOM / SAX / JDOM

• XML:DB XUpdate
• Usable today
• Useful beyond just XML databases
• W3C XQuery update extensions
• Expected at some point in the future
• Will not be part of XQuery 1.0
• Experimental syntax does exist
XUpdate Example

<xu:modifications version="1.0" xmlns:xu="http://www.xmldb.org/xupdate">

<xu:remove select="//*[@name='John']"/>
<xu:update select="/addresses/address[1]/city">
Las Vegas
</xu:update>
</xu:modifications>
Schemas

• Most native XML databases are schema

independent
• DTDs - Just say no
• Proprietary or extended DTDs
• W3C XML Schema will likely be supported
more widely in the future.
The Bad
• Products are immature
• Many standards are still in development
• Techniques are unfamiliar to people
• Not good at transaction processing
• Tool support is minimal
• Some expected database practices are still
unsupported
• Interoperability between products is minimal
The Good
• Good way to store XML
• Can store document or data style XML
• Tremendous flexibility
• Applications can be loosely coupled
• Data modeling is simple and flexible
• Complement RDBMS with XML mapping
solutions
• Performance can be very good
The End

Questions?
 XSLT In a
Nutshell
Paul Prescod,
Blast Radius Products
Co-Author: XML Handbook
paul@prescod.net
What is XSLT

A language for transforming XML:

– From a structural vocabulary like DocBook to a
presentation vocabulary like HTML
– Between similarly vocabularies
– Even within the same vocabulary
Batch Formatting

 Transform XML into vocabulary suitable for

display
 Most common targets:
– HTML (for legacy display)
– XSLT Formatting Objects (one day)
Direct Browsing of XML Files

 Transform on client side

 Browser can apply XSLT style sheets that
produce HTML
 Browser directly displays the HTML
Inter-vocabulary Translation

 Any input vocabulary is legal

 Any output vocabulary is legal
 Even:
– Proprietary
– Non-visual
"Massaging" Data

 Querying for particular information

 Sorting on elements and attributes
 Filtering elements and attributes
 Output could be new vocabulary or old one
"Dumbing Down" Data

 Formatting-oriented transformations "dumb-

down" data
 Domain-specific, semantic elements become
generic, formatting-oriented elements
Reusing Data

 For
example, in the online rendering of an
XML document representing an
encyclopedia, the article title might be:
– in the page that represents the article itself
– in the header
– in the footer
– in the Table of Contents
– in a "listing by author"
– in a "listing by subject"
– in cross-references
Example: Input

<repairs>
<repair>
<date>...</date>
<location>...</location>
<reason>...</reason>
</repair>
<repair>
<date>...</date>
<location>...</location>
Example: Output

<table>
<headings>
<head>Location</head><head>Date</head><
head>Reason</head>
</headings>
<row><cell>...</cell><cell>...</cell><cell>...</ce
ll></row>
<row><cell>...</cell><cell>...</cell><cell>...</ce
ll></row>
Transformational Features

 Headings row added

 Location and date switched around
 Elements renamed
– Repairs --> table
– Date --> cell
– Location --> cell
– Reason --> cell
Transformation Terminology

 XSLT Stylesheet = collection of "template

rules"
 Template Rule = pattern + template
 Every input element is processed with a
single rule
 The "right rule" is found based on pattern
 The rule applies the template
Formatting Terminology

 Templates create result elements

 Result elements can conform to any
vocabulary
Result Element Vocabulary

 Depending on namespace, could be:

– HTML: can be displayed by legacy a browser
– “XSLT Formatting objects”: displayed by FO-
aware browser or printed
– other vocabulary: further processing as needed
XSLT and HTML

 Modern and legacy browsers understand

HTML
 XSLT can generate HTML
 HTML generation can be done on client or
server
 6.0 browsers allow generation on client
XSLT and XSL FO

 Used more often for print than online

 Future browsers may understand XSL
formatting objects…but probably not
 "FOP" tool can batch-convert them into PDF
 Commercial tools also support xsl:fo. For
instance Renderx (has SVG support!) and
Antenna House
XSLT Versions

 The current version is 1.0.

 2.0 is being designed. It is somewhat more
complex and sophisticated.
 It builds on XPath 2.0, which is strongly type-
checked.
 It supports all XML Schema types and can do
appropriate conversions between them.
 XPath: Node
Addressing in XML
What is XPath?

 Data must be found before it can be worked

with
 Document components can be located by
– name (components with URIs or IDs)
– position (in document hierarchy or character
stream)
– structural relationship (to some other located
component)
 XPathis a simple query/addressing language
for XML
A Basic XPath

 Return the root (document) element if it is of

type DOC
 /DOC
 It is just like a DOS or Unix path referencing
a file in the root directory
Path-like XPaths

 Return the TITLE child (assuming there is

only one) of the DOC document element
 /DOC/TITLE
Query-like XPaths

 Returnall SECTION children of the DOC

document element
 /DOC/SECTION
Multi-level XPaths

 Return all TITLE children of all SECTION

children of the DOC document element
 /DOC/SECTION/TITLE
Wildcards in XPaths

 Return all TITLE children of all children of the

DOC document element
 /DOC/*/TITLE
 In other words, all TITLE grandchildren
 The wildcard matches elements of any
element type
 It matches only one level
Matching Multiple Levels

 Return all TITLE nodes anywhere within all

DOC/SECTION elements
 /DOC/SECTION//TITLE
 Return all TITLE nodes anywhere within all
SECTION elements anywhere within the
DOC document element
 /DOC//SECTION//TITLE
 Return all TITLE nodes anywhere within the
document: //TITLE
Matching Other Node Types

 Get all child text nodes from TITLE children

of DOC
/DOC/TITLE/text()
 Get all comments

//comment()
 Get processing instructions

/DOC/processing-instruction()
Matching Parents

 ..represents the parent node

 Return elements directly containing
FOOTNOTEs
//FOOTNOTE/..
 Return footnoes’ parent elements' TITLE
children
//FOOTNOTE/../TITLE
Matching Attributes

 @foo represents an attribute named "foo"

 Security attributes of SECTION:

//SECTION/@security
 All security attributes in document

//*/@security
Evaluation Context

 Every XPath is evaluated in a context:

– For an XPointer used in a link, the context is the
root of the document into which it points
– In XSLT, the context is "the node you are working
on" (the current node)

 To get the context node itself, use "."

Relative XPaths

 The XPath ./P (or just P) finds all elements of

type P that are children of the context node
 The XPath ./* (or just *) finds all elements of
all types that are children of the context node
Understanding Context

<DOC>
<SECTION ID="Top-level">
<SECTION ID="Contained.1"/>
<SECTION ID="Contained.2"/>
</SECTION>
</DOC>
 In the context DOC,
 XPath: SECTION (or ./SECTION)

Predicates
 Filter result nodesets
 Predicates are specified with square
brackets
 The most common types of predicates
are:
– attribute existence
– subelement existence
– position
Attribute Predicates
 Sections with a security value of
"TOPSECRET"
 //SECTION[@security="TOPSECRET"]
 Sections with a security value defined
 //SECTION[@security]
 All name attributes of elements with
security attributes
 //SECTION[@security]/@name
Subelement
 Sections Predicates
containing an image
 //SECTION[IMG]
 Sections containing an image with a
caption
 //SECTION[IMG/CAPTION]
Positional Predicates
 A numeric predicate tests that a node
corresponds to a position
 Selects third SECTION
 //SECTION[3]
 Selects last SECTION
 //SECTION[last()]
 Selects second last SECTION
 //SECTION[last()-1]
 Third SUBSECTION of fifth SECTION
 /DOC/SECTION[5]/SUBSECTION[3]
Predicate Expressions
 To refine an address, in a predicate you
can use
– other location path expressions
– strings
– numbers
– operators, including or and and to express
alternates or unions
– functions (XPath defines a core set)
CoreFunctions
XPath's core function library includes
– node set functions, e.g.: id(), last(),
position(), count()
– string functions, e.g: contains(),
starts-with(), normalize()
– boolean functions, e.g.: true(),
false(), lang()
– number functions, e.g.: number(), sum(),
round()
Some
=Equality
: equal Operators
 != : not equal
 <, > : less/greater than
 <=, >= : less/greater than or equal to
Boolean Operators/Functions

 or: e.g.
section[@title or @name]
– (one or other)

 and:
– section[@title and @name]
 (both)
Numeric Operators
 + : add
- : subtract
 div : divide
 * : multiply
 mod : modulus
Conversion Functions

 number()
 string()
 boolean()
Alternates

 We can express a logical union

 Elements of element type a or b:
 a|b
 Nodes that are either "a" elements or text
nodes
 a|text()
XPath overview)
Unabbreviated Syntax
 (quick
 XPath is a set of steps separated by "/"
 Each step can have:
– "axis"
– "node test"
– "predicate"
 axis::nodetest[predicate]/axis::nodetest
[predicate]
 ./child::p/attribute::align
Extending Functionality

 Systems that use XPath can add functions

and features to suit their needs
 Most XSLT implementations add their own
features.
 XSLT Basics:
Extracting Data
with Templates
In and Out

 Input to an XSLT process is

– a transformation or template, and
– a source document

 Output is an XML tree or text file

 In XSLT, the terms "stylesheet" and
"transformation" are interchangable
 INPUT
XSLT Process
OUTPUT
Source
Tree
Result Tree
XSLT or
PROCESS Text File
Output
Template:
Stylesheet/
Transformation
Transformations and templates

 XSLT can be used for "transformations" and

for "template documents"
 XSLT "template document" is a single
template transformation
 Most transformations are made up of many
templates
 Templates pull information out of documents
 A transformation alternates control between
templates and the document
An Input Document

 In an XSL-implementing browser:
<?xml version="1.0"?>
<?xml-stylesheet href="stylesheet-name.xsl"
type="text/xsl"?>
<book><title>Catch-22</title>
<logo url="catch22.jpg"/>
<description>...</description>
</book>
 Put the stylesheet declaration after the XML
Pulling information into Output

 Template document:
<html xsl:version="1.0"
xmlns:xsl="
http://www.w3.org/1999/XSL/Transform">
<head><title>A document</title></head>
<body>
<p>Here is the title of the book:
<xsl:value-of select="/book/title"/>
<img src="{/book/logo/@url}"/>
XSLT Namepace

 The real XSLT Namespace is:

http://www.w3.org/1999/XSL/Transform
 Some older stylesheets support an Internet
Explorer 5 syntax:
"http://www.w3.org/TR/WD-xsl"

 Run away! These stylesheets depend on

behaviors that are slightly different than the
standard.
Template components

 Blindly reproduced to output:

– Elements not in the XSLT namespace (literal
result elements)
– Text in the stylesheet (literal text)

 Processed to produce output:

– XSLT instructions (elements in the XSLT
namespace), e.g. xsl:value-of
– Attribute templates in literal result elements
(delimited by curly braces {}
xsl:value-of

 xsl:value-of outputs a computed value

 select attribute computes value
 Usually used to fetch data from input tree
– e.g. <xsl:value-of selelct=“/book/title”/>
Value of a Node

 The value of a text node is its character data

 The value of an element is the character data
of all of the text nodes directly contained or
contained by descendants of the element
 The value of an attribute is the character data
in its literal value
 Full
Transformations
Stylesheet constituents

 Instructions at the top level

– affect the entire transformation process
– include template rules (<xsl:template>) and other
instructions and declarations

 Instructions within templates

– direct recursive template application (<xsl:apply-
templates>)
– direct data extraction (xsl:value-of)
– govern creation of particular output nodes
<xsl:template>

 <xsl:template> elements contain most of the

code for an XSLT transform
 <xsl:template> elements define template
rules
 A template rule matches input nodes to an
output template
 E.g. "when you see an EXAMPLE element:"
– "Make a horizontal line."
– "Output the text 'Example'."
Template Rule Anatomy

A match attribute on <xsl:template> contains

the pattern for choosing input nodes for
processing
 The <xsl:template> element's content is the
template to be applied to the matching nodes
– literal result elements (e.g. <h1>)
– literal text (e.g. "Hello")
– "xsl:" instructions (e.g. xsl:apply-templates)
A Template Rule

 This example uses HTML result element

types:
<xsl:template match="EXAMPLE">
<hr/> <!-- horizontal rule -->
<p>Example
<xsl:number level="any"
from="chapter"/></p>
<pre> <!-- PRE element -->
<xsl:apply-templates/>
Rule Dependence

A rule for an element may need to process

other elements ("nodes")
 E.g. 1: A rule for processing a chapter is
dependent on rules for processing
paragraphs
 E.g. 2: A rule for processing a cross-
reference may be dependent on a rule for
processing the target element
"Recursive" Rule Application

 The stylesheet uses the "root rule" (or a

default)
 That rule calls rules for its children (because
it is dependent on those rules)
 ...And so on, and so on, down the tree
 Each rule calls other rules using the
“xsl:apply-templates” instruction
Which rule to apply?

 There are many rules

 Each rule knows how to handle certain
elements, but not others
 Each rule has a pattern that describes what
rule applies
 Pattern syntax is a subset of XPath
Example Document

<doc>
<section>
<title>…</title>
<p>…</p>
</section>
<section>
<title>…</title>
<p>…</p>
Example Transformation

<xsl:stylesheet version="1.0"
xmlns:xsl="http://…">
<xsl:template match="doc">
<html>…<body>
<xsl:apply-templates/>
</body>
</html>
</xsl:template>
Example (cont’d)

<xsl:template match="section">
<div>
<xsl:apply-templates/>
</div>
</xsl:template>
Example (cont’d)

<xsl:template match="section/title">
<h1><xsl:apply-templates/></h1>
</xsl:template>
<xsl:template match="p">
<p><xsl:apply-templates/></p>
</xsl:template>
What if no rules match?

 There are implicit default rules built into every

stylesheet
 These rules are called automatically if no
other rule matches
 The built-in default rules process sub-
elements and output text
 You could override them with your own
default rules, but you would rarely do so
<xsl:apply-templates>

 The <xsl:apply-templates> instruction goes

within <xsl:template> content
 The processor processes each node with the
applicable template
 By default, apply-templates processes all
sub-elements and text nodes of the current
node.
The select attribute

 The element can have a select attribute that

tells the processor which nodes from the
input node set to process
 Otherwise it processes all child nodes.
Simple Example

 Goal: transform a slideshow in XML into

something simpler
 Target DTD is similar to HTML
 All element type names are from HTML
Input

<slideshow><title>My Title</title>
<slides>
<slide><title>Slide 1</title>
<point>Point 1</point>
<point>Point 2</point>
</slide>
<slide><title>Slide 2</title>...
</slide>
Output

<html>
<title>My Title</title>
<h1>My Title</h1>
<hr/>
<h2>Slide 1</h2>
<ul>
<li>Point 1</li>
<li>Point 2</li></ul>
XSLT Design Procedure

 Do the work required to make a minimal

stylesheet
 Examine your input document type
 Start from the top (root, or document
element)
 Handle document element's sub-elements
 Handle their sub-elements, etc.
The Minimal Stylesheet

<?xml version="1.0"?>
<xsl:stylesheet
version="1.0"
xmlns:xsl=
"http://www.w3.org/1999/XSL/Transform">

<!-- Template rules go here -->

Starting at the Top

 Sketching the slideshow output template

<xsl:template match="slideshow">
<html>
<title>...</title>
<h1>...</h1>
...
</html>
</xsl:template>
slideshow Element Type

<xsl:template match="slideshow">
<html>
<title>
<xsl:apply-templates select="title"/>
</title>
<h1>
<xsl:apply-templates select="title"/>
</h1>
title Element Type

 We just want the text

 Our children are all text nodes
 Text nodes are automatically output

<xsl:template match="title">
<xsl:apply-templates/>
</xsl:template>
slides Element Type

 We just want to handle the children

<xsl:template match="slides">
<xsl:apply-templates/>
</xsl:template>
 Look familiar?
 This rule is so common it is built-in
 So we didn’t really have to do these rules at
all!
slide Element Type

<xsl:template match="slide">
<hr/>
<h2>
<xsl:apply-templates select="title"/>
</h2>
<ul>
<xsl:apply-templates select="point"/>
</ul>
point Element Type

<xsl:template match="point">
<li><xsl:apply-templates/></li>
</xsl:template>
We're done!

 XSLT Stylesheet evaluation will start with the

root node
 The root node represents the whole
document
 Evaluation will proceed to the document
element node (slideshow)
 Then to each of its children
 ...And so on, and so on
Final Stylesheet - 1

<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl=
"http://www.w3.org/1999/XSL/Transform">
Final Stylesheet - 2

<xsl:template match="slideshow">
<html>
<title>
<xsl:apply-templates select="title"/>
</title>
<h1>
<xsl:apply-templates select="title"/>
</h1>
Final Stylesheet - 4

<xsl:template match="slide">
<hr/>
<h2><xsl:apply-templates
select="title"/></h2>
<ul><xsl:apply-templates
select="point"/></ul>
</xsl:template>
<xsl:template match="point">
<li><xsl:apply-templates/></li>
Executing the XSLT Processor

 saxon [xmlfile.xml] [stylesheet.xsl] >

[output.xml]
 saxon simple.xml simple.xsl > simple.htxml

 Goodchoices for processors include Xalan,

MSXML, Saxon, 4XSLT
Exercise: subpoints

 How could we implement subpoints?

<slide><title>A slide title</title>
<point>A point
<subpoints>
<point>First subpoint</point>
<point>Second subpoint</point>
<point>Third subpoint</point>
</subpoints>
Exercise: subpoints cont'd

<h2>A slide title</h2>

<ul>
<li>A point
<ul>
<li>First subpoint</li>
<li>Second subpoint</li>
<li>Third subpoint</li>
</ul>
Implementing subpoints

<xsl:template match="subpoints">
<ul>
<xsl:apply-templates/>
</ul>
</xsl:template>
Will this rule ever get called?

 Yes: the point rule will call it

<xsl:template match="point">
<li><xsl:apply-templates/></li>
</xsl:template>
 Template Recursion
SOURCE RESULT

slide <ul>
point <li>...

subpoints <ul>

point <li>...</li>
... ...
</ul>
...
</li>
Looping

 xsl:for-each lets us do the same thing for

many nodes
 The body of the xsl:for-each is a full template
 It is instantiated once for each match
 Each time a different node is the "current"
node
Example of Looping

<xsl:template match="repairs">
<TABLE>
<xsl:for-each select="/repairs/repair">
<ROW>
<TD><xsl:value-of select="date"/></TD>
<TD><xsl:value-of select="location"/></TD>
</ROW>
</xsl:for-each>
Current Node

 Relative location paths are relative to the

current node
 The current node is also available through a
current() function
<xsl:for-each select="/class/instructor">
Teacher:
<xsl:value-of
select="/teachers/teacher
[@name=current()/@name]"/>
Conditional
Processing
Conditionals: xsl:if

 E.g.: Only build a Table of Figures if there

are figures
<xsl:if test=".//figure">
<h1>Table of Figures</h1>
<ul>
...
</ul>
</xsl:if>
Conditionals: <xsl:choose>

 xml:choose is necessary when you need

multiple options
 xsl:otherwise is like "else"
 Only one option is chosen, or else
xsl:otherwise is used
Using <xsl:choose>

<xsl:choose>
<xsl:when test="..[@type='chapter']">
Chapter</xsl:when>
<xsl:when test="..[@type='appendix']">
Appendix</xsl:when>
<xsl:otherwise>
Section</xsl:otherwise>
</xsl:choose>
Advanced Feature
Overview
Creating Element Nodes
 In addition to literal result elements,
xsl:element instructions can be used in
templates to create new element nodes
<xsl:element
name="p"
namespace="http://www.w3.org/HTML">
</xsl:element>

<xsl:element
name=”{@real_tagname}"
Computing Attribute Values

 The xsl:attribute instruction creates a new

attribute node, or replaces the value of an
existing attribute node, on the containing
element:
<img>
<xsl:attribute name="src">
<xsl:value-of select="/book/logo/@url"/>
</xsl:attribute>
</img>
Text Nodes

<xsl:text>This is text</xsl:text>
 xsl:text is good for inserting whitespace:

<xsl:text> </xsl:text>
Numbering Nodes in Output
 xsl:number creates a formatted number for
insertion in output tree (Overview!)
<xsl:number
level = "single"|"multiple"|"any"
count = pattern
from = pattern
value = number-expression
format = {string}
lang = {nmtoken}
Processing Instructions

<xsl:processing-instruction
name="xml-stylesheet">
href="book.css"
type="text/css"
</xsl:processing-instruction>
 creates the PI:

<?xml-stylesheet href="book.css"
type="text/css"?>
Comments

<xsl:comment>This file is automatically

generated. Do not edit!</xsl:comment>
 creates the comment:

<!--This file is automatically generated. Do not

edit!-->
Copying

 xsl:copy-of:copy of a result-tree fragment

 xsl:copy: easy way of copying the current
node
xsl:copy-of

<xsl:template ...>
<xsl:copy-of select="/foo/bar"/>
</xsl:template>
 Copies selected elements from source to
result
 Children are also copied
 Can also insert result tree fragments:

<xsl:variable name="myvar">
<a><b/></a>
xsl:copy

<xsl:template match="p">
<xsl:copy/>
</xsl:template>
 Namespace nodes of the current node are
automatically copied
 Attributes and children of the node are not
automatically copied
xsl:variable

 Variable values can be numbers, strings,

booleans, node-sets
 It is also possible to hold "result tree
fragments":
<xsl:variable name="res-tree">
Hello, my name is:
<xsl:value-of select="@name"/>
</xsl:variable>
 name attribute is name of variable
Using xsl:variable

<xsl:template match="student">
<xsl:variable name="student-name"
select="name"/>
Congratulations
<xsl:value-of select="$name"/>!
<xsl:value-of select="$name"/>, you are
soon to be the winner of our
sweepstakes! Your friends will
Parameters

 Parameters are inputs from the "application"

 Could be specified through:
– command line arguments
– browser GUI
– environment variables
– .ini file

 If not specified, they "default"

xsl:param

<xsl:param name="foo">
Hello, my name is
<xsl:value-of select="@name"/>.
</xsl:param>
<xsl:param name="foo"
select="/foo/@default"/>
 A missing default is equivalent to empty
string
Template Calling

 xsl:apply-templates
 xsl:call-template

<xsl:call-template name="foo"/>
 xsl:call-template is like apply-templates but:
– template is chosen by name
– mode and select attributes are irrelevant
– does not change current node
Passing parameters
 xsl:with-param:

<xsl:call-template name="foo">
<xsl:with-param name='myparam1'>
value
</xsl:with-param>
</xsl:call-template>
<xsl:apply-templates/>
<xsl:with-param
name='myparam'
Modes

 Whatif we need the same element to be

processed in many different ways?
– As a heading
– As a TOC entry
– As an index entry
– For cross references

 Weneed to write four different rules that

apply to the same element
Using Modes

A template can declare that it only works in a

particular mode
<xsl:template match="..." mode="...">
...
</xsl:template>
 An apply-templates instruction can declare
that it needs a template that has a certain
mode:
<xsl:apply-templates select="..." mode="..."/>
Modes Example

<xsl:template match="SECTION">
...
</xsl:template>
<xsl:template match="SECTION"
mode="TOC">
...TOC handling...
</xsl:template>

<xsl:template match="BOOK">
Using Additional
Stylesheets
Inclusion Instructions

 xsl:include: include another stylesheet

 xsl:import: include ... with lower precedence
xsl:include

 Includes another stylesheet

 Absolute:

<xsl:include href="http://.../foo.xsl"/>
 Relative:

<xsl:include href="foo.xsl"/>
 Stylesheets may not include themselves
directly or indirectly
Import Instructions

 Like inclusion except that definitions in the

importing stylesheet take precedence over
those in the imported stylesheet
 Absolute:

<xsl:import href="http://.../foo.xsl"/>
 Relative:

<xsl:import href="foo.xsl"/>
Input Management
Input Descriptions

 xsl:key: define searchable index

 xsl:namespace-alias: equate two
namespaces
 xsl:strip-space: define space stripping
element types
 xsl:preserve-space: define space preserving
element types
Keys

 Keys allow you to look up elements by name:

– Customers by phone number
– Chapters by a unique identifier
 The same element can be have two keys:
– Employees by employee ID
– Employees by social security
Key Example: info.xml

<employees>
<employee employeeID="e98302">
<social-secur>000-00-0000</social-secur>
<name>Anthony
Sobers</name></employee>
<employee employeeID="e02322">
<social-secur>111-11-1111</social-secur>
<name>Mossy Rock</name></employee>
</employees>
Declaring Keys: foo.xsl

<xsl:stylesheet ...>
...
<xsl:key
name="employees"
match="employee"
use="@employeeID"/>

<xsl:key
name="soc-sec"
Using Keys: foo.xsl

<xsl:template match="department">

<xsl:value-of
select='key("employees","e98302")/name'/>

<xsl:value-of
select='key("employees",@empid)/name'/>
Avoiding Name Clashes

 What if you want to generate an XSLT

stylesheet, or have software that searches
for HTML title elements?
 How do you make an xsl: or html: element
without triggering XSLT or HTML
processing?
xsl:namespace-alias

<xsl:namespace-alias
xmlns:axsl="http://something/bogus"
stylesheet-prefix="axsl"
result-prefix="xsl"/>
<xsl:template match="/">
<axsl:stylesheet>
...
</axsl:stylesheet>
Space Stripping

 In machine to machine applications,

whitespace between nodes is usually
irrelevant
 xsl:strip-space strips space from specified
elements
 Strip space from address and date elements:

<xsl:strip-space elements="address date"/>

 Strip space from all elements:

<xsl:strip-space elements="*"/>
Space Preserving

 Ifcertain element types need spacing to be

preserved:
<xsl:preserve-space elements="foo bar"/>
Output Management
Output Descriptions

 xsl:output:
various output options
 xsl:decimal-format: printing numbers
xsl:output
 (Quick overview!)
<xsl:output
method = "xml" | "html" | "text" | other
version = nmtoken
encoding = string
omit-xml-declaration = "yes" | "no"
standalone = "yes" | "no"
doctype-public = string
doctype-system = string
Error Management
Messages

 xsl:message generates messages

 Presentation depends on application:
– GUI dialog box
– standard error
– logfile
<xsl:if test="not( /foo/bar )">
<xsl:message>
Sorry, you need a /foo/bar
</xsl:message>
Fallback

 Ifyou see xsl:foo and don't know how to

handle it, you should look for an xsl:fallback
element
<xsl:foo>
<xsl:fallback>Sorry, your XSLT processor
doesn't have that feature!
</xsl:fallback>
</xsl:foo>
More Information
 Specs:
– http://www.w3.org/TR/xslt
– http://www.w3.org/TR/xpath.html
– http://www.w3.org/TR/xslt20/
– http://www.w3.org/TR/xpath20/
 Several good books:
– XSLT : Programmer's Reference by Michael Kay
(Author)
– Beginning XSLT by Jeni Tennison
– XSLT and XPath On The Edge by Jeni Tennison
– Definitive XSLT and XPath by G. Ken Holman
 Mailing list:
– http://www.biglist.com/lists/xsl-list/