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

[Abel Braaksma Online <abel.online@xxxxxxxxx>]

> 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!
Abel