This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re[2]: xsl 1.1 security model?


  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]