Subject: Re: [xsl] [XSL] XSL Browser Integration|
From: "M. David Peterson" <m.david@xxxxxxxxxxxxx>
Date: Fri, 14 Sep 2007 08:35:16 -0600
On Thu, 13 Sep 2007 19:38:07 -0600, Abel Braaksma <abel.online@xxxxxxxxx> 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.
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. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155