Re: [xsl] xsl:include with plain text input

[Peter Davis <pdavis152@xxxxxxxxx>]

On Friday 15 February 2002 01:10, Jeni Tennison wrote:
> Hi Peter,
>
> > I remember seeing this discussed in an article somewhere, but now I
> > can't find it. My problem is that I have several plain text files
> > (*.js, which are ECMAScript scripts) that I would like to output
> > along with the rest of my stylesheet's output. <xsl:include>
> > obviously doesn't work, because it expects a stylesheet as input.
> > Are parsed entities capable of accepting plain text as input?
>
> Parsed entities have to be well-formed - they have to follow the same
> rules as the content of an element. For plain text files, the result
> of this rule is that any less-than signs or ampersands in the document
> need to be escaped as they would in an XML file (you need to escape
> greater-than signs as well if they appear in the sequence ]]>).
>
> That usually means that you can't just use a JavaScript script as an
> external parsed entity, since JavaScript tends to use less-than signs
> and ampersands quite a lot.

I was not aware that this was possible; I just assumed that parsed entities 
had to be a complete document, with a root element and such.  That gives me 
the following solution: surround the entire document with a CDATA section 
that is commented out:

/* <![CDATA[ at the beginning */
function myScript() {
  bevocal.log("woo hoo! it works!");
}
/* ]]> */

This way if the scripts are used separately they aren't confused by '&lt;' 
and '&amp;' everywhere and are not confused by the <![CDATA[ ]]>, and when 
used as a parsed entity, the comments are also ignored.  Working around 
escaping of actual ']]>' sequences is fortunately not a problem in my scripts.

>
> Nor can you use the document() function to access such a document --
> the document() function only works on well-formed XML documents, so as
> well as escaping less-than signs and ampersands being escaped, you
> also need to add a document element wrapped around the text.

Using document() would be cleaner, but if parsed entities can handle it, then 
that is what I will use until XSLT 2.0.

>
> This is a recognised problem, though. The XSLT 2.0 Working Draft
> describes an unparsed-text() function that basically works in the same
> way as the document() function, but allows you to access a plain text
> document. See http://www.w3.org/TR/xslt20/#function-unparsed-text for
> details. I don't think that Saxon 7.0 supports this function.

I can't wait until XSLT 2.0 comes out, for this and other reasons.  Seems 
like they should have thought of this before.

>
> Depending on your setup, you might alternatively be able to use
> XInclude to include information within your XSLT stylesheet. An
> XInclude processor should be able to take a document and insert the
> referenced text file in the place of an XInclude element. You could
> use the XInclude processor either on the stylesheet prior to
> transformation or on the result following transformation. See
> http://www.w3.org/TR/xinclude/ for details. Cocoon, for example, has
> an XInclude Transformer that you could use either on the stylesheet or
> on the result of the transformation (see
> http://xml.apache.org/cocoon/userdocs/transformers/xinclude-transformer.htm
>l).
>
> [I tried looking through the AxKit documentation but didn't find
> anything about support for XInclude there - glad to be corrected if
> anyone knows otherwise. You would probably be able to use an XSP page
> or something similar to achieve the same effect.]
>

That is also a great idea, but the range of environments in which my 
stylesheet must be deployed prevents me from having anything but fully 
compliant XSLT 1.0 (getting the clients to support that is hard enough) :).

> Cheers,
>
> Jeni
>
> ---
> Jeni Tennison
> http://www.jenitennison.com/
>

Thank you very much for your extremely helpful answers.

-- 
Peter Davis
This fortune intentionally not included.

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