Symphony.

I am trying to build a site from scratch (not using the default workspace). I have gone ahead and created a katastatiko.xsl page and a master.xsl utility.

There is a datasource that provides this XML: source.xml

The output was rather weird. It included the text of data/param elements and the katastatiko.xsl output. After much digging around the information on the web it became apparent that the built-in templates where kicking in.

So I went ahead and added <xsl:template match="text()" /> in the master.xsl and now, since the 3rd built-in template is overriden with this empty template.

But the question remains, why would the built-in function trigger? Is there a better way to circumvent this?

You probably didn't have a template for the root element data, so the default template kicked in. I usually have a template for data in my master utility or in the page xsl itself.

@klaftertief Thanks for the input. I just tried your recommendation changed <xsl:template match="/"> in master.xsl to <xsl:template match="data"> but still the output remains.

I think klaftertief's right. However, if you change your master.xsl template to /data instead of / the default template will kick in for params, which probably explains the extra stuff in the output.

Have you tried mimicking how the default ensemble does it? Keep <xsl:template match='/'> in your master.xsl and change <xsl:template match='data/katastatiko'> in your katastatiko.xsl to <xsl:template match='data'>. (You'd have to change the for-each accordingly.) This way you can have other data sources attached to your page and your XSL will be flexible.

If you want to keep <xsl:template match='data/katastatiko'>, you can try putting in an empty template <xsl:template match='data'> along with your data/katastatiko template in katastatiko.xsl.

@River Thanks a lot mate, it seems that what you proposed fixed it. Now the built-in template does not process. Still unclear as to why, but it works. ;)

Your master template is fine, you'll just need to modify the katastatiko.xsl to be more like this

@designmonkey: Yes, that works too, thanks a lot, I am still struggling to find out why I need to match the first element after the root (data) for the built-in functions not to trigger. It seems to me that it is inconsistent and that it should be the same for a child of that element (data/katastatiko) (meaning the built-in templates shouldn't kick in.

Maybe II'll do some exploring later on a deeper level i.e.: match=data/katastatiko/entry to see if the built-in template gives in for the data/katastatiko as it does for the data in my first post.

I am still struggling to find out why I need to match the first element after the root (data) for the built-in functions not to trigger.

data isn't the root node, / is. XML needs to have one single node after the root to contain it's children, and that node mistakenly gets called the root node, when it actually isn't.

If you we're calling from a deeper lavel, match=data/katastatiko/entry wouldn't work, as it would look for a child node data from the level you were at, whereas match=/data/katastatiko/entry would match as you start from the root node. So if you called match=data/katastatiko/entry from a root template like in master.xsl then that would match, as data is a child node of the root.

Hope it makes sense..?

I am still struggling to find out why I need to match the first element after the root (data) for the built-in functions not to trigger.

data isn't the root node, / is. XML needs to have one single node after the root to contain it's children, and that node mistakenly gets called the root node, when it actually isn't.

Exaclty what I talked about, first element after the root node is data ;)

Anyhow, I went ahead and kicked the tires on what I described on my previous post and it does seem to be the case. Here is the setup:

• katastatiko2.xsl
• master2.xsl
• source
• output

Ah, no you've not got what I meant.

So if you called match=data/katastatiko/entry from a root template like in master.xsl then that would match, as data is a child node of the root.

What you've done in your example is match two templates starting from root, so you will still see the incorrect output coming from /. If you remove the template that matches / then everything will work in that example, but the solution I gave you is what you're trying to achieve.

I think I see it now. Yes, the solution you've provided is indeed what I was after, River's worked too ;)