[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Novice Question - matching entire text children

Subject: Re: Novice Question - matching entire text children
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Mon, 20 Dec 2010 11:28:12 -0500
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 !

That's why I wrote "Ha Silly Me".

I tried something that 'seemed obvious' to an XSLT novice to discover it was
a synatax error.

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).

I'm writing XSLT *dynamically* based on a schema.   This is not hand-written
XSLT but very obtuse XSLT generated by XQuery based on a XSD Schema,
various annotations and external configuration files (with some Java thrown
in for fun).

( Part of my JSON/XSLT transformation experiment/project).

I need to *paramatize*  generation of different parts of an element in a
given element.

For example, an element like

<ELEM a1="value1" a2="value2">Text</ELEM>

I need to paramtize and independantly generate the rules for :

A) How to generate the element "ELEM" (various ways)
B) How to generate the attribute a1  (as apposed to attribute a2 which may
be generated differently)
C) What to do with text nodes.

I'm going to try to avoid the details  as there are many and I havent
written the paper yet :)

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.

So for my *first attempt* I'm generating templates based on the element, its
attributes, AND ITS TEXT as separate templates.
e.g.

<template match="ELEM" .>  ...
<template macth="ELEM/@a1">  ...
<template macth="ELEM/@a2">  ...
<template macth="ELEM/text()">  ...


These templates are generated in different parts of the code all based on various configuration information and annotations in the schema. SO I never know easily which rule is going to kick out where, and I certianly don't know within the generation of matchign for "ELEM" what the coresponding templates to call are for its attributes or text ... so I just pass the buck and am trying to leverage XSLT's pattern matching for me to avoid the problem. Trying to leverage FULL push matching instead of PULL matching so I can decouple the rulebases ...

Beyond that I don't think I can explain better until I finish the code and
write the paper ...
Its *kinda working* right now ... but trying to improve it.

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
======================================================================

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.