Re: xsl 1.1 security model?
Chris Bayes wrote: > > > I think the best approach to this would be to change HTML to support > > frame-sets which include HTML code rather than just references to > > other HTML documents. Of course, this is simply to keep the entire > > page generated in a single XSLT tansform. > > > > An approach which works today is to have a frame set, and then each of > > the HTML "pages" referenced in that frame set would be XSLT transforms > > for each of the frames. No need for xsl:document at all. > > I don't follow that but trying to get my head round it made me think of > <xsl:target name="_top"... as opposed to or as well as <xsl:document > href="_top"... or maybe <xsl:document href="browser://_top"... > Sure would save a lot of typing. > I don't see the problem anyway. Has anyone played with xml.save() or > xmlhttp.open()/send() recently? > There are a couple of alternatives, if slightly hypothetical: [a] the XSLT approach - <frame name="top"> <xsl:attribute name="src"> <xsl:text>data:</xsl:text> <xsl:call-template name="top-content"/> </xsl:attribute> </frame> (this relies on the browser supporting the data: scheme, which as far as I know, only Netscape does. It would probably also require the value of the src attribute to be URL-encoded.) [b] the XPointer approach - <FRAME SRC="myTransform#xpointer(/content/top)" NAME="top"> <FRAME SRC="myTransform#xpointer(/content/middle)" NAME="middle"> ... I'm wildly assuming that the browser might be able to do some cacheing of the entire myTransform document, wothout having read it up or considered other implications (like the fact you don't normally want to cache generated documents). Francis. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format