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

1. A Use-Case Driven Approach to the Development of Reusable Stylesheet Modules Terry Brady LexisNexis

2. 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”

3. 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

4. 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

5. 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!

6. Very Contrived Examples • Input DTD’s • article.dtd • instructions.dtd • Output DTD’s • book.dtd • faq.dtd

7. 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)

8. 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)

9. 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)

10. 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)

11. General (default/meta) title paragraph section step makebook makefaq default rule, warn on unmapped elements In:title  out:header in:para & in:emph in:sectionout:section man:step/man:num root  book:book root  faq:faq Modules Needed

12. 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

13. Create Use Cases • Only as complex as needed to illustrate one case • Validate understanding before coding

14. Create Contrived Use Cases • Title • Paragraph • Section • Step • Article • Manual

15. 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>

16. 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>

17. 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.

18. 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

19. 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

20. 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

21. 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

22. Unit Test Driver Source Code Management Use Case Files Stylesheets Baseline output Schematron, & Template DTD Use Case Files Baseline output Use Case Files Baseline output Runtime Directory

23. Copy Resources to runtime area Source Code Management Use Case Files Stylesheets Baseline output Schematron, & Template DTD Use Case Files Baseline output Use Case Files Baseline output Runtime Directory Use Case Files Stylesheets Baseline output Schematron, & Template DTD Use Case Files Baseline output Use Case Files Baseline output

24. Iterate over use case files Runtime Directory Use Case Files Stylesheets Baseline output Schematron, & Template DTD Use Case Files Baseline output Use Case Files Baseline output

25. Copy use case file with fully resolved DTD (if using catalog) Runtime Directory Use Case Files Stylesheets Baseline output Schematron, & Template DTD Use Case Files Baseline output Use Case Files Baseline output Use Case File Copy This makes it easier to view the input file in a browser that is not catalog aware

26. Report the validity of use case file Runtime Directory Use Case Files Stylesheets Baseline output Schematron, & Template DTD Use Case Files Baseline output Use Case Files Baseline output

27. Find each stylesheet referenced by the use case file… Runtime Directory Use Case Files Stylesheets Baseline output Schematron, & Template DTD Use Case Files Baseline output Use Case Files Baseline output A single use case could serve as input to multiple stylesheets

28. If the stylesheet references a template, compile a new stylesheet. Runtime Directory Use Case Files Stylesheets Baseline output Schematron, & Template DTD Use Case Files Baseline output Use Case Files Baseline output Compiled stylesheet This is to allow the creation of a custom import tree when testing an individual module

29. If the stylesheet references a schematron file, compile the schematron and perform semantic validation on the use case file. Runtime Directory Use Case Files Stylesheets Baseline output Schematron, & Template DTD Use Case Files Baseline output Use Case Files Baseline output Compiled stylesheet Compiled Schematron This permits the enforcement of boundary/scope conditions for a styesheet.

30. For each dtd referenced in the use case file or stylesheet, apply the stylesheet to the use case file. Runtime Directory DTD Use Case Files Stylesheets Baseline output Schematron, Template, & DTD Use Case Files Baseline output Use Case Files Baseline output Compiled stylesheet Output file Set the system identifier of the output file to the referenced DTD. Validate transformation output to all appropriate targets

31. Report on the validity of the output file. Runtime Directory DTD Use Case Files Stylesheets Baseline output Schematron, Template, & DTD Use Case Files Baseline output Use Case Files Baseline output Compiled stylesheet Output file Set the system identifier of the output file to the referenced DTD.

32. Apply transformation to use case file without referencing an output DTD. Runtime Directory Use Case Files Stylesheets Baseline output Schematron, Template, & DTD DTD Use Case Files Baseline output Use Case Files Baseline output Compiled stylesheet Output file

33. If a use case file references a schematron, compile the schematron and perform semantic validation on the output file. Runtime Directory Use Case Files Stylesheets Baseline output Schematron, Template, & DTD Use Case Files Baseline output Use Case Files Baseline output Compiled Schematron Output file

34. If a baseline file exists that matches the output file, perform a comparison of the two files. Runtime Directory Use Case Files Stylesheets Baseline output Schematron, Template, & DTD Use Case Files Baseline output Use Case Files Baseline output Output file

35. Generate a summary report of test execution Runtime Directory Use Case Files Stylesheets Baseline output Schematron, Template, & DTD Use Case Files Baseline output Use Case Files Baseline output Summary Report

36. Summary Report

37. 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“

38. 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