XSLT + Xpath

1. XSLT + Xpath CS196-9

2. High level view • We are doing tree editing • Changes to node properties • Structural rearrangement • Several mdels for this kind of task

3. Models for tree editing • Functional • Rule-based • Template-based • imperative

4. Functional tree rewriting • Recursive processing • Invoke start function at the root, construct a new tree • Can think of this as “node functions” • Result is “compositional” — substitution is generally nested • Side effects generally avoided: caching values, clarity.

5. Rule-based (rewriting systems) • Idea is that one has a list of patterns • Each is a piece of a tree with holes for variables. • A match leads to replacement of the matched tree by a result • Variables shared between pattern and result allow movement of data • Poweful, incremental, definitions; non-deterministic processing

6. Template based processing • This is a model in which a pattern document is the starting point • It contains literal results interleaved with queries and/or imperative code • Well-suited to rigid structures • Often requires extensions to deal with recursion

7. Imperative • Parser calls imperative code, which uses: • Stacks • Global variables • Explicit output commands • Result is a side effect. • Reasoning about the program may be hard, but creating it often starts out easily.

8. What’s the big drawback to tree editing? • Buffering! • You need a copy of the tree to edit • This means that it’s very easy to build transformer for a document entirely in-memory • Doing this from secondary storage is fairly subtle, and has it’s own performance penalties • This is a complex speed/size/coding effort tradeoff

9. XSLT falls squarely into the middle of these approaches • Rule-based substitution (but the RHSs look a lot like template languages • Xpath addressing looks more like the kinds of patterns used in traditional template languages • Limited non-determinism • Sufficient control over rule evaluation order that functional transformations are easy • No side effects (in standard language)

10. Styles of XSLT transform • Functional • Rule-based • Template-based • Imperative

11. Weirdnesses of XPath • Navigational language for specifying pattern matches • You don’t match a portion of a tree explicitly, rather a node. • You can invoke further processing on children • You use template-style access functions rather than pattern variables

12. Weirdness… • The language is a mixture of predicate and structural pattern • Path syntax and functional syntax not a really fortunate mix • Matching is always relative to a particular node, so the first few times results can be very puzzling

13. Strategies for XSLT • Try to pick a single style as much as possible • May vary by project • Mixing may be necessary but can get confusing • Be sure you understand (and probably override the default rules) • Shorter patterns are better • <xsl:value-of> and <xsl:if> may be easier to deal with than a complex path

14. Strategies… • Use several filters in row • It’s often easier to manage a series of global changes, than interactions between several complex conditions. • Intermediate results make debugging easier • Intermediate results may be cacheable • Critical for online applications • Where possible code things one element at a time

15. XPath • Based on an analogy to Unix path syntax • An XPath is composed of “steps” • Each step starts at the context node, and moves