This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: including files
- From: Mike Brown <mike at skew dot org>
- To: xsl-list at lists dot mulberrytech dot com
- Cc: n8_shaw at yahoo dot com
- Date: Tue, 9 Jul 2002 12:09:08 -0600 (MDT)
- Subject: Re: [xsl] including files
- Reply-to: xsl-list at lists dot mulberrytech dot com
I wrote:
> I think you're on the right track. I would use document() but instead of
> pointing directly to the file, point to a URI that, when resolved, will
> deliver a well-formed document. You usually have the option of customizing the
> URI resolver (see JAXP's javax.xml.transform.UriResolver interface, and
> setUriResolver() on the Transformer or TransformerFactory) so that it delivers
> whatever you need.
>
> For example, for document('urn:nate-frag.xhtml'), your URI resolver
> could look for 'urn:nate-' and then know that it needs to return
> something like
>
> <?xml version="1.0" encoding="utf-8"?>
> <!DOCTYPE wrapper [ <!ENTITY content SYSTEM "frag.xhtml"> ]>
> <wrapper>&content;</wrapper>
I kind of wish I could find a better example. We all allude to the 'custom
URIResolver' approach, but we never provide any code samples :)
Anyway I wanted to add that the concept of 'resolving' a URI in some places
means just merging a given relative or absolute URI with an absolute base,
producing just a new URI string. And sometimes, it is assumed to mean that you
not only merge the two strings, but you also return a representation of the
identified resource. The JAXP URIResolver does this, returning a Source
implementation (DOMSource, SAXSource, or StreamSource, usually).
I decided about 9 months ago that I like Python a whole lot better than Java,
so someone else will have to post an example!
- Mike
____________________________________________________________________________
mike j. brown | xml/xslt: http://skew.org/xml/
denver/boulder, colorado, usa | resume: http://skew.org/~mike/resume/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list