[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: XSL and Web Native distributed computing, was Re: HTML is a


Subject: Re: XSL and Web Native distributed computing, was Re: HTML is a
From: Guy_Murphy@xxxxxxxxxx
Date: Tue, 27 Apr 1999 10:12:50 +0100

Hi Jonathan.

I read you post with keen interest as it addresses distributed computing,
and goes beyond the document-centric view of XML/XSL and considers the "Web
application". I've been trying to track related areas myself, and firmly
believe that FOs are just the starting point, and wondered if others had
considered a future set of presentation objects to address GUIs?

Sites that I've found of interest when considering this matter have been
http://www.skinz.org and http://www.mozzila.org (for XUL).

There are alot of people out there putting alot of effort into coding apps
that have plugable interfaces, and shells where the interface is abstracted
from functionality and likewise fully pluggable. It would seem the has been
very little cross-fertilisation between this community and the XML/XSL
community, each of them seeking there own ways of describing and
implementing interfaces.

And it got me to thinking, if we had a rich set of presentation objects
addressing the description of GUIs, then not just Web applications but
shells also could be built from the same stuff. In such a case we would see
not so much browsers wrapped in a folder as in Win95, but the shell as a
global user agent. Then Web apps could merge seemlessly with the shell, and
we could start looking at true distributed computing.

The other benefit of course would be that customisation of the shells form
and appearance would be simple, with the knock on of leaving the user agent
in control of handling presentation of Web apps.

What really got me thinking is http://www.webos.com (the server was
throwing an error when I tried to check it this morning) which although
effectively is only a functional mock-up caught my attention because it was
looking at many of the issues I have been considering. And that is the
concept of a fully deliverable interface. At present I have been using HTCs
in order to prototype GUI presentation objects, and I see no reason why
not, and many reasons why this paradigm would be a good one to persue.

It is right and proper that we consider documents as our starting point,
but with regard to XML and XSL we should be considering not just the next
10 months, but the next 10 years.

Over this period of time I think the persuit of Web applications, and the
persuits of easily describable interfaces for shells and applications
*will* meet, it's just a question of whether they meet with an embrace or a
crunch. Netscape and MS are already making inroads into this area, both
with very divergent strategies, as is everybody else's strategy.

Can XSL or an adjacent spec provide the unified description of the GUI to
extend the Web beyond the document to both the application and onto the
desktop?

Personally I find the term document rather abitary, and feel that sooner or
later we have to move out view past it.

Cheers
     Guy.






xsl-list@xxxxxxxxxxxxxxxx on 04/27/99 12:48:40 AM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  XSL and Web Native distributed computing, was Re: HTML is a




[SNIP]
    For real distributed systems development, especially on the Internet,
the bottle neck is round trips (perhaps even more than bandwidth). If one
document can be downloaded to a client and then transformed this way and
that, select a fragment here, display a toolbar there etc. etc. etc. 'Web
native' applications can approach the responsiveness and rich UI of
traditional client server applications e.g. VB, Powerbuilder, C++.
    The screen to screen delay which is a rule with typical client HTML,
server CGI/ASP etc. is largely eliminated by downloading a bunch of data to
the client and then interacting with it (the initial download is part of
the
'application load time' which users have become accustomed to). XSL
transformations glued together by a bit of Javascript are a great way to
accomplish this.
    If the browser has a good bidirectional java interface, xt for example
would be a great transformer though the jar file is about 500 kb (and
without XFO support). Oh well. Does Opera JavaScript allow access to java
applets? Do applets have access to the HTML DOM?
    On the other hand, the justification for charging $ 35 for the Opera
browser is so enhancements can be made. This is quite reasonable. I would
hope that rigorous implementation of the XSL standard would be judged a
worthy place to invest some of the money generated from the sale !,000,000
browsers.
Jonathan Borden
http://jabr.ne.mediaone.net



 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
Keywords