Subject: Canonical Result Nodes From: crism@xxxxxxxxxxxxx (Christopher R. Maden) Date: Fri, 10 Mar 2000 01:21:46 -0800 |
At XTech, a cow-orker and I presented a proposed heuristic for determining the "canonical" result node for a given source node. The problem is that when there is a link to a particular node in a source tree, but the user is interacting with a formatted result tree, what is presented as the result of following that link? A longer description of the problem and proposed solution is below. What I am particularly interested in is non-degenerate examples where the heuristic fails; if anyone can come up with any, please reply. Thanks, Chris Identifying Canonical Result Tree Nodes ======================================= Every result tree node is generated by a combination of a source tree node (possibly the root node of the source tree) and a template. But one source tree node may be instantiated multiple times. When an XPointer identifies a node in the source tree, which result tree nodes should be presented to a user who requests them, e.g. by following an XLink to that node? Some consideration shows that not all result nodes are equal. Consider the case of a chapter in a book. The chapter is instantiated once "as itself" - evident to any human reader as the canonical result. But a cross-reference to the chapter will most likely be presented by transforming the chapter through a cross-reference template; the selection should present the user with the obvious canonical result node. However, in the case of a source node presented on an equal basis in multiple locations, for example a node in a document generated from a database that presents multiple views of the data, multiple instantiations of a node may be equally meaningful to the user. We believe that a fairly simple heuristic can do the right thing in nearly all cases: 1. Select all nodes that result from instantiating the target source node. 2. If some of the selected result nodes were instantiated in the stylesheet's default mode, eliminate any that were not. Typically, "special" processing of nodes is performed in different modes, such as the cross-reference above. This filters those nodes. 3. If any of the remaining result nodes were generated from a template whose match pattern matched the source node, eliminate any other nodes. A source node can be processed within the body of a template with an xsl:for-each element or an xsl:value-of. If a node is processed with those methods in some places, but is processed with its own template elsewhere in the stylesheet, it is highly probable that the user will prefer the result of the template over that of the special context. 4. If multiple result nodes remain, the user agent should present the XPointer as though it were an aggregate identifier. -- Christopher R. Maden, Solutions Architect Yomu (formerly Exemplary Technologies) One Embarcadero Center, Ste. 2405 San Francisco, CA 94111 XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
probably a stupid question (fwd), Carole E. Mah | Thread | More namespace fun?, Pawson, David |
Re: XSL Theory, Jon Smirl | Date | Re: xsl for formatting, Sebastian Rahtz |
Month |