>Doesn't this strike anyone else but me as a serious flaw. It >basically requires that all extension calls must occur in a single >monolithic template.
XSLT can be made to do what you want, but it won't be elegant. However, I think you're getting into the space where what's impressive is not how well the bear dances, that he dances at all. If it really bothers you, it could be worked around in various rather ugly ways, eg by having the extension store the data in a pool somewhere and return only a string which can be used to retreve it from that pool. (Beware of the possibility of out-of-order execution!) But in many cases, I think it's possible to rewrite the problem description to avoid the need. For example, have the extension return its data in XSLT-compatable form (which would probably make your extension more generally resuable by other stylesheets anyway) and convert it back when the next extension wants a Java-level view of it. Remember that XSLT isn't intended to be a fully general nonprocedural programming language -- its focus is query, limited operations upon the data returned by the query, and recomposition. Using it to glue together extensions talking to other extensions really wasn't one of the primary design goals. XSLT-2 might change that (I've just started reading the current working drafts, so I don't know)... but I'd be somewhat surprised if it did.
