Re: [xsl] [XSL] XSL Browser Integration

On Thu, 13 Sep 2007 19:38:07 -0600, Abel Braaksma <abel(_dot_)online(_at_)xs4all(_dot_)nl>  
wrote:
> At anytime when a browser invents a new thing, it is not cross browser  
> compatible.
Oh, of course!  I'm not suggesting browser companies stop inventing new  
things, just that when these same things don't provide any obvious benefit  
beyond that which can be achieved using a standards compliant method then  
it doesn't make sense to use these methods instead of the cross-browser  
standards compliant method.
> Nobody uses XHR in the early days: too complex was the comment. Now it  
> is one the hottest new technologies (opinion vary).
True.  But XmlHttpRequest has obvious benefit that goes beyond using a  
0width/0height iframe (e.g. setting header values, selecting the  
appropriate HTTP verb for the request, etc.) which is the only real  
"competitor" the XHR has in terms of a standards compliant method of  
obtaining data using asynchronous calls to the server to gain a partial  
page refresh of data.
>  Ok, this is not so much of a new hot technology. It is a minor feature.  
> But we are talking about inclusion through parameters. It is a  
> convenience method.
I guess I just don't see how this is more convenient.  Whether the  
parameter values are contained in the data or as PI's, it's still a part  
of the original data file, and the PI method comes with the disadvantage  
of being non-queriable once the XML has been parsed as the PI's get thrown  
out.  Of course you would still be able to access them inside your  
transformation file via $paramName, but unless I've missed something you  
can only provide an atomic string value as part of the select statement  
which in and of itself makes absolutely no sense.  There's no XPath  
selection taking place.  It's a hard coded string, so in many ways you're  
at a significant disadvantage by using this method than you would be  
otherwise.
>  Depending on your server side environment, it is likely that you have  
> one source for XML. This way you do not need to change this XML and you  
> can still add metadata through parameters.
You've lost me.  Why couldn't I just put all of my parameters and related  
values in a separate static XML file and use the document() function to  
access them?  If that file never changes then a well behaved browser will  
use a conditional GET to determine whether or not it should use the cached  
data file, and if yes you've now saved the additional over-the-wire cost  
of including that data in the master data file.
>  But of course, the whole design concept around PI / XSLT is kind a bad.
Well it's good for what it was designed for: As a modified #ifdef  
statement. Of course that's assuming the folks who designed the PI did so  
from the perspective of mimicking #ifdef functionality.  I've always  
assumed this was a PI's designed purpose, but have never actually done the  
historical research.
Can someone with a deeper understanding clarify one way or the other?

> If a server file looks like this SSI file (probably won't compile, but  
> you get the idea)
> <?xslt-param name="date" value="<!--#echo var='DATE_LOCAL' -->"?>
> <?xslt-param name="ip" value="<!--#echo var='IP_REFERER' -->"?>
> <?xml-stylesheet mystylesheet.xslt ?>
> <!--#include file="some-generated-xml-file.xml" -->
>  In this scenario it is unlikely that it is handy to change the xml info  
> on-the-fly, because that means re-parsing in a system where you already  
> include it via some SSI call. In that use case, it can be handy to  
> simply extend your SSI file with some dynamic parameters, or a CGI  
> inclusion.
Why would a server side include of XML data force a server side re-parse  
of that same data?  There would be no reason to reparse it.  If the XML  
writer was designed correctly it would validate the output as it's being  
written (or better said it wouldn't output invalid XML in the first place.)
>  But all this is, indeed, fairly useless unless other browsers implement  
> this too.
I still think it would be useless even if other browser manufacturers were  
to support it.  But maybe I'm missing something completely obvious?
--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155
--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--