[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: why split? [was RE: XSL intent survey]
Hi, I fact, XSL processor will be implemented on the client side as "protocol handlers" or "filters", more specifically as filters. These filters are associated to a particular MIME type, when that MIME type is recognized by the browser, it check to see for a filter associated to this MIME type. If there is one, this latter is called to process the file or stream. The filter could be a XSL processor that takes as input a XML stream and output a HTML stream. This filter then tell the browser that the MIME type is changed to HTML and this latter then render the HTML stream. We are currently implementing a DSSSL filter with that mechanism. Microsoft implemented a XSL filter with the same mechanism. Some groups are modifying Modzilla to implement a filter mechanism. Modzilla already has a protocol handling mechanism but no filter mechanism. As soon as the group releases the modifications on modzilla.org, it will be possible to implement a MIME type filter without having to look at the source and you know how easy it is to look at Modzilla source code :-). So, when that Modzilla improvement will be ready, the same filter mechanism (with minor differences in interfaces) will be possible on both browsers. Thus, there is no need to implement a XSL, DSSSL or xxxxL processor as a proxy, just a browser's MIME filter is sufficient. I look forward to see alternative XSL MIME filters. Actually I have no choice than to have Microsoft XSL implementation. All other XSL processors are not part of the client's browser. If, for example, KOALA implementation would be as a MIME filter, we could experiment with it on the client side but just typing a something like "http://mysite.com/mydocument.xml and get it rendered seamlessly. If there is any transformation language provider on this list, my question is: when do you will provide a XSL processor packaged as a MIME type filter? Is it because Microsoft already provide one? if yes then Microsoft XSL processor is the facto standard on explorer, then there is now who will implement for _free_ a XSL MIME filter on Netscape (remember the GNU model?). Any announcements? Actual state of the business: Microsoft provide a XSL client side processor. No alternatives on the market that provides a user seamless experience when browsing a XML document(the best implementation is a MIME filter because it don't require from the user to set a proxy) No actual XSL processors integrated as MIME filter on Netscape. Any announcements on that side? This means that most of actual XSL processors (implementations different than Microsoft)are server side. Even on this side, we tested the Microsoft XSL processor and discovered (we were surprised) that it can be used in a ASP page. Do any other XSL processor could be used in a ASP page? When we tried to test other XSL processor we discovered that most of them (and there is not a lot of them) that they have to be called from a procedural language on the server. The procedural language is called as a CGI or fastCGI or whatever format from the server and the "script" itself call the XSL processor. So there, it seems that Perl or Python with strong pattern match extension are strong competitors to XSL. Conclusion: Do anybody work on a client side XSL implementation? if yes, will it be packaged as a MIME type filter? If not, is it because Microsoft already provides one? If that is the case, Microsoft XSL client processor is the facto standard on Explorer. Do anybody work on a client side XSL Modzilla implementation? If yes, will it be as a MIME type filter? Will it be in _tune_ with modzilla model? I mean here will it be free and included in Modzilla? If not, until the government resolve the monopoly issue, we will have two browsers one with a free XSL client processor and one with a fee based client. ON the server side, is there any implementation that do not need to be bootstrapped by a procedural language? I mean here a XSL processor implemented as a CGI or whatever format compatible with HTTP servers?. Here it is, more questions than answers, but at least I we get answers to these questions we will know how the market will resolve standard issues ;-) Didier PH Martin mailto:martind@xxxxxxxxxxxxx http://www.netfolder.com > -----Original Message----- > From: owner-xsl-list@xxxxxxxxxxxxxxxx > [mailto:owner-xsl-list@xxxxxxxxxxxxxxxx]On Behalf Of > Guy_Murphy@xxxxxxxxxx > Sent: Thursday, November 26, 1998 6:42 AM > To: xsl-list@xxxxxxxxxxxxxxxx > Subject: Re: why split? [was RE: XSL intent survey] > > > Now that's a creative solution. > > I'm going to have to ponder on that one, as it's caught me sort of > sideways. > > I know that MS ASP Remote Scripting uses a Java proxy to buffer data > between the client document and the server, so I suppose there's no reason > why such a proxy shouldn't be an XSL parser recieving XML. > > Do you know is anybody working on such an implimentation? > > Regards > Guy. > > > > > > xsl-list@xxxxxxxxxxxxxxxx on 11/25/98 06:15:31 PM > > To: xsl-list@xxxxxxxxxxxxxxxx > cc: (bcc: Guy Murphy/UK/MAID) > Subject: Re: why split? [was RE: XSL intent survey] > > > > > > Guy_Murphy@xxxxxxxxxx wrote: > >Think on it this way... I can run XSL transformation on a server, not > using > >formatting objects, simply using the transformative part of XSL, delivery > >HTML to the client browser. Given the wide ranging support for HTML 3.2, > on > >a practical level I need never worry about the rendering abilities of the > >client. > > > > ... > > > >In short the scenario I describing is en effective replacement for the > >likes of ASP and PHP on the server when dealing with XML. If I can't > >process XML with XSL and get the desired result tree I wanr, then I'm > >pretty much going to stick with an ASP/PHP like option. I suspect that > many > >other developers would make a similar choice. > > Yes. In fact, there's a second interesting alternative - transfer the XML > to > the client, and convert it to there, then give it to the browser. > Given the > existing 100% Java XSL processors, this can be done by an applet > inside the > browser. If the XML is much smaller then the generated HTML, this trades > CPU > cycles on the client for bandwidth - a reasonable tradeoff these days. > Oren. > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > > > > > > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > 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
|