Re: [xsl] XSLT 1: From flat XML to tree hierarchy XML. Can't seem to find the right way to do it.

Subject: Re: [xsl] XSLT 1: From flat XML to tree hierarchy XML. Can't seem to find the right way to do it.
From: Abel Braaksma Online <>
Date: Fri, 26 May 2006 09:40:17 +0200
Perhaps the input changed? If, for example, the namespace changed, my
example would have stopped working unless it was updated to reflect
the new namespace.

hmm, really, no. I had two input docs: the one I provided in this thread, and the one provided by my operational system, both failed on later on. Namespaces where not the issue, because that would've meant seeing nothing or only a couple of non-namespaced elements. I wasn't clear on what was wrong: I missed the items that were both a tree (by there category attributes) and an element at the same time.

But I figured that I may not have looked well enough to the output. Some items where missing or were not doubled and I clearly remember to have seen both the categories and the items separated on first run. But the categories names where replaced by text of the tableName items on later reads. I think I just needed a good sleep and stop being delirious ;)

That does add to the complexity, the match I specified to catch the
1st tableName/@category-name basically prevents you from doing a
simple apply-templates to include it in your container.

This actually convinced me that I really must have been dreaming the first time. Now it is all clear as rain that things were the way they were ;)

It is similar to what you are doing, but it shows how you can
use mode selection to keep the code which emits an 'item' element in
one place.

Yes, I could've thought of that, I guess. I often end up using parameterized call-templates, but this is really way easier!

I think your use of literal result elements is fine, I've thought of
it as just a matter of style. I'd be curious if people on this list
have opinions on whether or not they've come up with rules for when to
use literal result elements and when to use xsl:element.

My personal taste for LRE is that most code highlighters are capable of highlighting HTML tag elements differently from XSL elements, and often even distinguish between XSL elements and XML elements. Code assisting often helps creating HTML too, and that won't work when using xsl:element. Finally, when just reading a stylesheet, especially if you are new to it (like some of my new employees are) it is easier to explain them what's happening when they see the LRE and explain them that anything *not* xsl will be part of the result tree automatically.

Of course, there are some situations where xs:element is needed (creating elements of which you don't know the name up front, for instance) and sometimes I find it handy to mix it: use xsl:attribute inside an LRE. This is definitely a choice of bad taste, but in big, complex result elements, it can add to brevity and clarity, I think, by grouping all fixed or AVT'ed elements on the LRE, and more complex attributes as xsl:attribute.

These are my "rules", but we do not enforced in our teams.

Cheers and thanks a bunch again, you really helped me out!

Current Thread