This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re[2]: xsl 1.1 security model?
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re[2]: [xsl] xsl 1.1 security model?
- From: Steven dot C dot Kienle at am dot pnu dot com
- Date: Mon, 26 Mar 2001 07:46:43 -0500
- Reply-To: xsl-list at lists dot mulberrytech dot com
In response to:
> I think the most material differences between "the publishing cycle"
> and "client-side rendering" are likely to be scaleability and
> security. I can imagine rendering requirements such as creating
> framed content that would really benefit from something like
> xsl:document if it could be done securely. But this would probably
> be scope-creep for a minor increment spec release...
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.
Steve
______________________________ Reply Separator _________________________________
Subject: Re: [xsl] xsl 1.1 security model?
Author: Francis Norton <francis@redrice.com> at Internet-America
Date: 26-03-2001 1:19 PM
Michael Kay wrote:
>
> >
> > And would an implementation that disabled the xsl:document element
> > client-side still be XSLT 1.1 compliant?
> >
> It's my understanding that Microsoft are reluctant to implement this feature
> client-side, and I think the spec is clear that it's not required for
> conformance.
>
Indeed, I should have spotted that
http://www.w3.org/TR/xslt11/#conformance states:
"A conforming XSLT processor need not be able to output the result in
XML or in any other form."
which implies that this feature need not implemented at all.
> This approach makes sense, since the requirement for the feature is mainly
> fur use during the publishing cycle, not in client-side rendering.
>
I think the most material differences between "the publishing cycle" and
"client-side rendering" are likely to be scaleability and security. I
can imagine rendering requirements such as creating framed content that
would really benefit from something like xsl:document if it could be
done securely. But this would probably be scope-creep for a minor
increment spec release...
Francis.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list