Re: [xsl] how to test for the element type of the current node

[Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>]

Godmar,

At 12:23 PM 7/2/2003, you wrote:
> That was actually one of the alternatives I looked at.  I discarded it 
> because
> I didn't know how to select "non-B children of A", now I know that you can 
> use
> match="A/*[not(self::B)]"  (true?)

You can, but generally matches on element types directly, not on 
"everything but". Sometimes you need to add explicit priorities to instruct 
the processor on which template is preferred.

> David pointed out that I could achieve my goal of handling B
> specially iff it's a child of A using a template matching A/B.
> In fact, using such a template would be required because xsl:template is
> not scoped and can only occur at the top level, so I can't put one
> inside the xsl:template for A.

Correct: if you want B elements occuring inside A to be different from B 
elements otherwise, you need a template matching "A/B". A plain match for 
"B" will catch the other B elements.

> This, btw, appears bad style: you're adding top-level elements
> to your XSL that really only have a meaning inside a subtree
> of your input DOM.  It's fragile because you have related pieces of
> style sheet spread out all over your style sheet, and it also seems
> prone to breaking if you ever change your DTD.
> (Maybe it's a design limitation of XSLT?)

This is generally considered a feature, not a bug. If you do much work with 
data such as documents, which have lots of elements appearing at different 
levels that should be treated the same, or not, depending... -- it turns 
out to be pretty nice that templates scope globally like this. (If all your 
data is highly structured, the benefits are less compelling). It has been 
argued that templates should be able to nest, but when you get into the 
details of such proposals, they turn out to be pretty hairy both in concept 
and execution. Instead, XSLT gives us modes, which (though again you have 
"related pieces of stylesheet spread out all over") can achieve the same 
effect when necessary.

(Mike K. suggested how you could use modes to deal with your "B in an A vs. 
B not in an A" case.)

As for prone to breakage -- if you design your DTD properly, "all children 
not a B" of an A element can be wrapped, if they are considered to be 
distinct from A *as a group*. One has to know how to design DTDs to support 
the maintenance and extensibility of the processing pipeline, not just the 
DTD itself. This, it is true, is something of an art.

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


XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list