Re: External Literal Result Elements?

> Hmm... put the literal result elements in separate stylesheets and
> xsl:include them in the master stylesheet where desired? Presumably these
> included stylesheets could be machine-generated. This is very similar to
> your option #1, "Store literal result elements as external parsed entities
> and insert appropriate entity references in the XSL file."

Using xsl:include is useful for compile-time only meaning that, once the XSL
file is compiled, the XSL processor can not be used in combination with
other sets of literal result elements.  Also, when the literal result
elements are changed, the XSL file have to be recompiled.

Using external entities also has the same effect if the entities are
expanded inline.  I guess the problem is that there seems to be no way to
control entity expansion.

In the spec, there was some mention of issues (data-ref and entity-ref)
which might have some relevance to the problem of using external literal
result elements.

In general, I like to be able to build an XML processor using XSL that
accepts not only a source tree but also a result template tree.  I do not
see an easy way to do this.

I guess the question this group should ask first is whether my problem is a
general one.  Is it?  Am I the only one who likes to change literal result
elements at runtime while using the same XSL file (or its compiled form)?

Best,

Don Park
Docuverse



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list