A Use-Case Driven Approach to the Development of Reusable Stylesheet Modules

A Use-Case Driven Approach to the Development of Reusable Stylesheet Modules

Terry BradyLexisNexis

Problem to Solve Collaborative XSLT Development Create useful modules that will

operate in multiple data conversions Multiple Input DTD’s Multiple Output DTD’s Team does not consist of schema

“experts”

Challenge Xslt containment not as easy as OO

containment Import precedence is trickier than

you think! Construction of the import tree can

radically alter the behavior of individual modules

Difficult to validate to multiple targets

XSLT Use Great for conversions Requires a shift in mind set Testing capabilities

Full support not there Or, so counter-intuitive everyone must

solve on their own

XSLT Modularity xsl:import

Creates import tree Import precedence overrides other precedence Great for named templates

xsl:include Creates a single logical module Precedence:

match specificity priority Position

Challenge with named templates!

Very Contrived Examples Input DTD’s

article.dtd instructions.dtd

Output DTD’s book.dtd faq.dtd

Article art:article

(in:title , in:section+) in:title

(#PCDATA|in:emph|meta:edit-by | meta:edit-date)* in:section

(in:title? , (in:para+ | in:section+)) in:para

(#PCDATA | in:emph | meta:edit-by | meta:edit-date)* in:emph

(#PCDATA | meta:edit-by | meta:edit-date)* meta:edit-by

(#PCDATA) meta:edit-date

(#PCDATA)

Instructions man:manual

(in:title , (in:section+ | man:step+)) in:title

(#PCDATA|in:emph | meta:edit-by | meta:edit-date)* in:section

(in:title? , (in:para+ | in:section+ | man:step+))> man:step

(man:num , in:para+) in:para

(#PCDATA | in:emph | meta:edit-by | meta:edit-date)* in:emph

(#PCDATA | meta:edit-by | meta:edit-date)* meta:edit-by

(#PCDATA) meta:edit-date

(#PCDATA) man:num

(#PCDATA)

Book book:book

(out:label? , out:header , out:section+) out:header

(#PCDATA|out:italics)* out:section

(out:label? , out:header? , (out:section | out:para)+) out:para

(#PCDATA | out:italics)* out:italics

(#PCDATA) out:label

(#PCDATA)

Faq faq:faq

(out:label? , out:header , out:section+) out:header

(#PCDATA|out:italics)* out:section

(out:label? , out:header? , out:para+) out:para

(#PCDATA | out:italics)* out:italics

(#PCDATA) out:label

(#PCDATA)

Modules NeededGeneral (default/meta)

title

paragraph

section

step

makebook

makefaq

default rule, warn on unmapped elements

In:title out:header in:para & in:emph in:sectionout:section man:step/man:num root book:book root faq:faq

Module Imports makebook.xsl imports section.xsl makefaq.xsl imports section.xsl

para.xsl imports general.xsl

section.xsl imports para.xsl, title.xsl, step.xsl

step.xsl imports para.xsl

title.xsl imports general.xsl

Create Use Cases Only as complex as needed to

illustrate one case Validate understanding before

coding

Create Contrived Use Cases Title Paragraph Section Step Article Manual

Title Use Case<?xml version='1.0' ?>

<?use-case scenario=Simple title;;stylesheet=stylesheets/demo/title.xsl?>

<!DOCTYPE in:title SYSTEM "../article.dtd">

<in:title>Hello</in:title>

Title with Metadata<?xml version="1.0" encoding="utf-8"?><!DOCTYPE in:title SYSTEM "../article.dtd"><?use-case scenario=Title with

metadata;;stylesheet=stylesheets/demo/title.xsl?>

<in:title>Hello<meta:edit-by>Terry</meta:edit-by><meta:edit-date>1/1/2006</meta:edit-date>

</in:title>

Create stylesheets Determine import hierarchy in

advance Call <xsl:apply-templates/>

wherever possible to allow the DTD to change

Iteratively test with use cases. Validate to DTD and schematron as

an additional tool.

Import Precedence Issue in:title processed fine by title.xsl in:para processed fine by para.xsl When executing the same files with

section.xsl in:para processed fine In:title processed by default rule

Introduce “template files” Construct the import tree as needed

for production Modular components reference a

“template file” via a processing instruction Inclusion of default rule Inclusive set of namespace declarations Testing-specific match rules

New import strategy makebook.xsl imports general.xsl, section.xsl makefaq.xsl imports general.xsl, section.xsl section.xsl imports para.xsl, title.xsl, step.xsl

References template.xsl via pi step.xsl imports para.xsl

References template.xsl via pi template.xsl imports general.xsl

Other Challenges Validating output of common

modules to multiple target DTD’s Supporting use cases appropriate to

a subset of target DTD’s Viewing results

Unit Test Driver

Use Case Files

StylesheetsBaselineoutput

Source Code Management

Runtime Directory

Use Case FilesUse Case

Files

BaselineoutputBaseline

output

Schematron, & Template

DTD

Copy Resources to runtime areaSource Code Management

Use Case Files

StylesheetsBaselineoutput

Runtime Directory

Use Case FilesUse Case

Files


output

Use Case Files

StylesheetsBaselineoutputUse Case

FilesUse Case Files


output


DTD


DTD

Iterate over use case filesRuntime Directory

Use Case Files


FilesUse Case Files


output


DTD

Runtime Directory

Use Case Files


FilesUse Case Files


output

Use Case File Copy


DTD

This makes it easier to view the input file in a browser that is not catalog aware

Copy use case file with fully resolved DTD (if using catalog)

Report the validity of use case fileRuntime Directory

Use Case Files


FilesUse Case Files


output


DTD

Find each stylesheet referenced by the use case file…

Runtime Directory

Use Case Files


FilesUse Case Files


output


DTD

A single use case could serve as input to multiple

stylesheets

If the stylesheet references a template, compile a new stylesheet.

Runtime Directory

Use Case Files


FilesUse Case Files


output

Compiledstylesheet


DTD

This is to allow the creation of a custom import tree

when testing an individual module

If the stylesheet references a schematron file, compile the schematron and perform semantic validation on the use case file.

Runtime Directory

Use Case Files


FilesUse Case Files


output

CompiledSchematron

Compiledstylesheet


DTD

This permits the enforcement of

boundary/scope conditions for a styesheet.

For each dtd referenced in the use case file or stylesheet, apply the stylesheet to the use case file.

Runtime Directory

Use Case Files


FilesUse Case Files


output

Outputfile

DTDSchematron,Template, &

DTD

Compiledstylesheet

Set the system identifier of the output file to the referenced DTD.

Validate transformation output to all appropriate targets

Report on the validity of the output file.

Runtime Directory

Use Case Files


FilesUse Case Files


output

Outputfile

DTDSchematron,Template, &

DTD

Compiledstylesheet

Set the system identifier of the output file to the referenced DTD.

Apply transformation to use case file without referencing an output DTD.

Runtime Directory

Use Case Files


FilesUse Case Files


output

Outputfile

Schematron,Template, &

DTD

Compiledstylesheet

DTD

If a use case file references a schematron, compile the schematron and perform semantic validation on the output file.

Runtime Directory

Use Case Files


FilesUse Case Files


output

Outputfile


DTD

CompiledSchematron

If a baseline file exists that matches the output file, perform a comparison of the two files.

Runtime Directory

Use Case Files


FilesUse Case Files


output

Outputfile


DTD

Generate a summary report of test execution

Runtime Directory

Use Case Files


FilesUse Case Files


output


DTD

SummaryReport

Summary ReportError Statistics

Use case file hierarchyTree Structure Hypertext to resourcesError messages

Input File Output File

Stylesheet, DTD, Schematron

Summary of methodology System architect defines stylesheet

modules Developer is assigned a module. Developer creates use case files. Use cases are reviewed Developer iteratively creates XSLT

module Stylesheet and output files are reviewed Output is "baselined“

Benefits Scope is defined for developer Developer demonstrates understanding

immediately Use case files serve as communication

tool Architect does not simply state

constraints. Constraints are enforced Regression test is built during

development

Documents

A Use-Case Driven Approach to the Development of Reusable Stylesheet Modules