[XSL-LIST Mailing List Archive Home]
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 <abel.online@xxxxxxxxx>
Date: Fri, 26 May 2006 09:40:17 +0200
Perhaps the input changed? If, for example, the namespace changed, myhmm, 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.
example would have stopped working unless it was updated to reflect
the new namespace.
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 theThis 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
1st tableName/@category-name basically prevents you from doing a
simple apply-templates to include it in your container.
It is similar to what you are doing, but it shows how you canYes, I could've thought of that, I guess. I often end up using
parameterized call-templates, but this is really way easier!
use mode selection to keep the code which emits an 'item' element in
I think your use of literal result elements is fine, I've thought ofMy 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.
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.
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!