[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

Subject: RE: why split? [was RE: XSL intent survey]
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Fri, 27 Nov 1998 11:03:30 -0500
ph proxy
Hi Guy,

OK I understand. What you call a proxy is, in fact, _a MIME type handler
which is like a protocol handler but specialized to handle a particular MIME
type. The concept of MIME type handler in modzilla is actually solely
related to plug-ins but there is work in progress to create the same kind of
functionality as Ms Explorer has. A filter that receives the stream and can
do transform to the stream content and give it back to the browser with its
new MIME type and let it render this MIME type (which may or not involve
plug-ins, activeX or applets). It means that, for instance, you receive a
XML MIME type and the MIME handler returns to the browser a HTML or RTF MIME
type. So to speak, the transform is not so much a structural transformation
as a MIME type transformation.

Status: MS explorer already has this feature. Modzilla has this feature in
construction.

To use a Java applet to do the job requires that you include the applet with
your document and get that document embedded in a HTML document. Thus the
HTML document act as a carrier of a) the applet, b) the XML document. Which
is probably not a good way to package a XML document :-) otherwise, why not
transfer it in already transformed in HTML format (except to reduce the
server workload but to increase the bandwidth and latency load).

to get an applet or Active X component that do a call to the server to do
the transform would also be not very efficient.

I hope that other software manufacturer will not use applet, active X or
plug-in to implement their XSL interpreter. At least not with the current
philosophy of having these components part of a HTML documents and have them
do the process within the HTML document context. The best solution (in
certain contexts)seems to be the "MIME handler" having the behavior
described above.

There is one drawback however, and we experimented it with DSSSL. When a big
document is downloaded (we used the XML Hamlet document from Jon Bosak and
technical ATA 100 docs, a SGML standard used in the aerospace industry) it
takes several seconds to be interpreted and transformed (always here only a
rendering transformation not a structural one). This process could be
accelerated with a cache mechanism like implemented with certain proxies.
That is why, I thought at first, that you were talking of proxies - because
of their caching capability. Thus, if the "MIME handler" maintains a cache
of already transformed documents, it could accelerate the translation
process. In fact, we discovered with a network usage that more than one
person could have the same document translated more than once (obvious you
say? :-) you're right). An intelligent proxy could not only keep in a buffer
documents (like they do today) but also transform them when required (like
for instance XML->HTML), keep the transformed document in the cache for
later usage.

At first, I thought that this is what you meant as a major reason for a
proxy with added transformation capabilities.

Do somebody else got similar experience with long documents? We experimented
with some technical documents like, for instance ATA100 based documents that
can easily be transformed from SGML to XML. As you know, technical documents
could be quite big sometimes. We got with microsoft XSL interpreter(written
in C++ and faster than other Java based XSL translator, no offence, its just
a fact and do not indicate any inclinations) , in certain case several
seconds interpretation time before the rendering occurred. We then got he
usual HTML interpretation and rendering delays which are not big numbers but
still there. Users found the process slow on 166 Mhz machines. On 300 Mhz
machines they couldn't notice the difference and in human time perception
wasn't perceived as slow :-) We got the same problem with DSSSL
transformation. So it seems that network with a big bunch of 166 or slower
machines may benefit from a proxy based mechanism. When we checked
commercial proxies, we discovered that they do not have the concept of MIME
handlers. In fact, are just, buffers and not transformation tools. I guess
we were a bit too fast for this market :-).

Question: maybe we didn't searched well and there is somewhere the pearl
that we need. If someone from this list knows one, can you send us a link?
do anyone knows a proxy server that can have kind of plug ins to do document
transformation - like for example - MIME handlers?

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: Friday, November 27, 1998 5:37 AM
> To: xsl-list@xxxxxxxxxxxxxxxx
> Subject: RE: why split? [was RE: XSL intent survey]
>
>
> Hi.
>
> I think the field got muddied over the term "proxy"... acting as a proxy
> with a smal "p" not a network Proxy Server... sorry if I confused anybody
> :)
>
> The reason why a proxy is desirable (or an ActiveX component, it's the
> fnctionality not the tech that's important) is because I produce largely
> dHTML sites, and it's highly desirable to be able to "squirt" the results
> of server mark-up into a chosen element. The MS Remote Scripting proxy
> makes it possible to execute a JScript function on a server, and recieve
> the result syncronously or asyncronously through the proxy as if
> it where a
> local function return. ie...
>
> myDiv.innerHTML = myRSFunction();
>
> Now the proxy is Java so it's possible to utilise RS on any browser
> supporting JavaScript and Java.... It would be nice to have an XSL parser
> moulded in a similar fashion. At the moment with have this
> functionality in
> IE5, but I see no reason why it could become common to impliment this on a
> wide range of browsers.
>
> Cheers
>      Guy
>
>
>
>
>
> xsl-list@xxxxxxxxxxxxxxxx on 11/26/98 10:55:09 PM
>
> To:   xsl-list@xxxxxxxxxxxxxxxx
> cc:    (bcc: Guy Murphy/UK/MAID)
> Subject:  RE: why split? [was RE: XSL intent survey]
>
>
>
>
> Hi,
> So let me try to understand your point. Why do you need a proxy and not a
> server based interpreter?
> A) is it because your server deserve several sub nets and you want to off
> load the server by having a proxy server on each net?
> b) your main target is Modzilla and actually there is no mechanisms
> (already
> completed) to add a XSL processor to the browser and therefore your
> solution
> is to add a proxy to the browser?
> c) you want to cache and pre-translate XML documents into, let's
> say, HTML?
> Your answer could help us understand your pre-requisites
> cheers
> 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 11:19 AM
> > To: xsl-list@xxxxxxxxxxxxxxxx
> > Subject: RE: why split? [was RE: XSL intent survey]
> >
> >
> > Hi.
> >
> > Sufficient for what purpose? Your purpose?... not mine :)
> >
> > I want a proxy, or at least the scriptable object currently available.
> > Direct browsing is one mechanism, but not always ideal.
> >
> > Cheers
> >      Guy.
> >
> >
> >
> >
> > xsl-list@xxxxxxxxxxxxxxxx on 11/26/98 04:11:37 PM
> >
> > To:   xsl-list@xxxxxxxxxxxxxxxx
> > cc:    (bcc: Guy Murphy/UK/MAID)
> > Subject:  RE: why split? [was RE: XSL intent survey]
> >
> >
> >
> >
> > [SNIP]
> > Thus, there is no need to implement a XSL, DSSSL or xxxxL processor as a
> > proxy, just a browser's MIME filter is sufficient.
> > [SNIP]
> >
> >
> >
> >  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
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.