[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The identity transform and attributes
Hi,
At 02:33 PM 1/21/2008, Andrew wrote: On 21/01/2008, David Carlisle <davidc@xxxxxxxxx> wrote: > select="child::foo selects the parent of the current node, > match="child::foo" asks if that node is the child of anything. > So unless you find it surprising that something can both have a parent > and be a parent, I'm not sure what is surprising here? Well, or it can be one of a couple of functions such as "id('x')", or it can be something like "forebear//progeny". Which seem to complicate things a bit, without really doing so, due to the rationale David is explaining. For example: ... at least as long as you assume there to be some sort of "stateful" relation between an expression used to select nodes, and the criteria used to match nodes to templates (that is, the rules for pattern matching, precedence and priority). Such an assumption may be natural enough in other processing paradigms, but as David has explained, in XSLT it's simply wrong. And indeed, XSLT gets much of its famous flexibility and power from this unlinking. To (seem to) change the topic, I recently learned that in Docbook, bibliomixed/link is invalid according to the schema, but it works just fine in the distributed stylesheets. Nor is this sort of thing uncommon in XML/XSLT. Why the discrepancy? Since, given the unlinking between selecting and matching, it's easier to write and maintain a stylesheet that "does the right thing" for a construct that is formally invalid, than it is to write a stylesheet that refuses. (In this case, an extra template would be required just to trap the invalid case.) This is because a robust stylesheet, in most cases, is actually easier and simpler to write than a brittle one. Underlying this fact is the simplicity of the match/select relationship and how much it does *not* assume about processing context. If you say it as "foo that is a child of some node" then it makes slightly easier to comprehend. And then when you think about it, all elements are children of either another element, or the root node (correct?) it makes sense that child:: is the default. Well, child:: isn't actually the default; rather, "child::foo" is the expanded form of "foo", which is a very normal (the most normal) sort of pattern to write, by design. What's especially interesting to me is how the rule for matching ("given node N and pattern P, does there exist in the tree some node X, from which, as context, node N would be selected using pattern P as a select expression?") is so intuitively workable that even experts can rely on it without being able to explain it. Notice that the rule says nothing about any expression ever actually used to select node N. I *think* that's a successful design. :-) Cheers, Wendell
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|