Francois Lachance (citing an anonymous off-list communication) wrote:

> >What types of trouble does a <text> element within <p> cause for the
> >writing of XSLT transforms?
> >
> you have to check each time you meet a <text> whether it is child of
> <TEI>; the behaviour is almost completely unrelated.
>
> I suppose its not a  big deal really, but it seemed odd to me when I coded
> it.

I should have thought that this check wouldn't really have to be repeated
every time. You could channel top-level text handling via a template
explicitly matching TEI.2/text or TEI/text, then handle all other <text>
nodes via a single additional template. The processor would keep track of
the TEI/text nodes and not process them twice (Well, more truthfully, it
would resolve match contentions in favour of the more specific pattern, but
the effect is the same). Might be necessary to use modes for some tricky
cases, but even then not really much coding or processing overhead, I
shouldn't think. That's assuming that the required behaviour really *is*
completely unrelated. If we are talking about, say <group>ed <text>s it
might not be. But then you could just tack //group/text on to the match
pattern for the top-level text handling template and keep the basic pair of
handlers.

But in general, I just hope this doesn't lead to a SIG to introduce text0,
text1, text2 ... textn I can sense some frightening analogies with the
rationale for numbered divs here. I think I will go and dig myself a bigger
bolthole just in case.

Michael Beddow