[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Novice Question - matching entire text children
Dear David,
On 12/20/2010 9:52 AM, David Lee wrote: I got that, but it was worth a try .... Cant learn without pushing the envelope ! Yep ... a little knowledge is a dangerous thing, etc. It's understandable that the novice might not know that 'string()' is a function, while 'text()' is a node test. A novice probably isn't going to know what the difference between a function and a node test is. Now to answer the pressing question I guess I cant get away from answering (because multiple people keep asking). It sounds like the paper will be really interesting. But I need to *conditionaly and parametrically* run different rules on different parts of even a signle element. These rules can be generated in different parts of the code. I'm sure there are a million ways to do this, but XSLT with its pattern matching capbility stood out as a good tool to use. Given what you're saying, it sounds like "ELEM/text()" is indeed the syntax you want. But hopefully your process won't be generating them very often. As Ken and David C both remarked, it's actually quite rare for a stylesheet to have to match a text node as such; almost invariably, a match on a containing element (or something else altogether) is a better and more robust solution. Among the interesting things to look at in your paper, I suspect, are (a) how whatever in-schema specification you have is expressed in the structure of the resulting stylesheet, (b) what differences there might be between XSLT generated this way vs the sort of vanilla, idiomatic push logic that a human expert such as Ken or David might write, and (c) whether these differences are consequential, and how. As for how, why and when matching on text() works, or doesn't, the devil is in the details, and we'd have to look at particular cases to do the analysis. (Of course, this won't discourage us from making generalized pronouncements while, or before, doing so.) Keep in mind that since this has to do with how the input tree is constructed -- something on the boundary of XSLT, not always within the processor's purview -- it is not impossible that information your parser and environment (not just the standard or even the XSLT processor) will be relevant. Cheers, Wendell -- ====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
|
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
|