Careful. I'm against the use of
<match src="something"> </match> <read/>
as well. The proper way should be
<match src="something"> ... </match>
<match src="**"> <reader/> </match>
having the logic processing not following the element nesting, is, IMO, very confusing and very bad practice.
In the original sitemap design, it was *NOT* possible to have pipeline components inside <pipeline>, only matchers. This is something that was introduced while I wasn't watching, just like actions.
Yes, actions are not the only the only things I dislike about the sitemap: the tree processor introduced new ways of dealing with things (like having resources without generators or serializers, or pipeline components in pipelines without matchers)... but all these things ended up being more harm than good from a usage perspective.
AFAIK it's not the tree processor's fault. Resources as pipeline parts where possible as far as I can remember :-) But with the compiled sitemap engine they must either call another resource or end with a serializer. Now (with the tree processor) the pipeline flow falls back to the calling pipeline, what allows e.g. transformer only resources.
Joerg
