Download
1 / 15
170 likes | 291 Vues
This document explores high-level methodologies for tree editing, focusing on modifications to node properties and structural rearrangements. It discusses various models including functional, rule-based, and template-based approaches, alongside imperative tree rewriting and recursive processing techniques. The text highlights strategies for implementing changes efficiently while balancing performance concerns related to tree buffering. Each method's unique characteristics are examined, with attention to the syntax and capabilities of XPath. Best practices and recommendations for effective XSLT transformation strategies are also provided.
E N D
XSLT + Xpath CS196-9
High level view • We are doing tree editing • Changes to node properties • Structural rearrangement • Several mdels for this kind of task
Models for tree editing • Functional • Rule-based • Template-based • imperative
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.
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
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
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.
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
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)
Styles of XSLT transform • Functional • Rule-based • Template-based • Imperative
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
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
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
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
XPath • Based on an analogy to Unix path syntax • An XPath is composed of “steps” • Each step starts at the context node, and moves
