Read a plain file from XSLT 1.0

[psaffrey@googlemail.com]

I'd like to read a one-line text file using an XSLT transformation.
I'm using libxslt, so I have to use XSLT 1.0.

This post:

http://www.stylusstudio.com/xsllist/200508/post50080.html

is promising, but I'm afraid I can't decipher it. Can anybody help?

Thanks,

Peter

[Richard Tobin]

Re: Read a plain file from XSLT 1.0

In article <f269b904-3e53-42a8-a0c9-73b7bea2b248@w7 g2000hsa.google groups.com>,
psaffrey@google mail.com <psaffrey@googl email.comwrote:

>I'd like to read a one-line text file using an XSLT transformation.
>I'm using libxslt, so I have to use XSLT 1.0.
>
>This post:
>
>http://www.stylusstudio.com/xsllist/...post50080.html
>
>is promising, but I'm afraid I can't decipher it. Can anybody help?

Mike is suggesting that you create another, XML, file that includes
your text file as an entity.

Suppose hello.txt contains your text - "hello world" for example.
Create hello.xml containing

<!DOCTYPE foo [
<!ENTITY ent SYSTEM "hello.txt" >
]>
<foo>&ent;</foo>

Then when you read foo.xml with the document function it will be as
if you had a file containing <foo>hello world</foo>. Of course,
you'll be in trouble if the file contains text that is ill-formed
XML.

As an extension to this idea, to save creating a separate file, you
could put an entity reference to the text file *in the xslt stylesheet
itself*, and use document("") to refer to the stylesheet. To do this
the name of the text file would have to be fixed.

-- Richard
--
:wq

[Joseph J. Kesselman]

Re: Read a plain file from XSLT 1.0

The other solution is to find or create an extension function which will
read and return the text file's contents. The advantage of this approach
is that, since you're returning it as data, it doesn't have to be a
well-formed XML Document Fragment; it can contain unbalanced <, >, -,
and & characters.

Depending on the details of your processor -- and what your stylesheet
actually does with the data -- it might still have to respect XML 1.0's
limitations on the legal character set. Unless the extension also
implements some custom escaping solution like <my:char ucode="3095"/>.

But this involves carving a large path into dubiously-portable
solutions. A better answer might be to write a separate preprocessor
tool which reads that file and writes out a safely XMLified version,
dealing with all of these issues in some appropriate manner... and then
have your stylesheet read and process that XML.