RE: why split? [was RE: XSL intent survey]

Subject: RE: why split? [was RE: XSL intent survey]
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Thu, 26 Nov 1998 08:11:37 -0500

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, 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 " 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

> -----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
> cycles on the client for bandwidth - a reasonable tradeoff these days.
> Oren.
>  XSL-List info and archive:
>  XSL-List info and archive:

 XSL-List info and archive:

Current Thread