<title>CWISP people meeting</title>
<H1>Argo etc</h1>
I had an all-day meeting with a number of people who had very kindly
flown in.
<p>From Cornell University there was
<a href=../../People/Worona.html>Steve Worona</a>.
Steve had a lot of useful input, playing devil's advocate in
querying the common assuptions of the UPenn and W3 teams.
<p>
Tim McGovern of MIT's Distributed Computing and Communications Services
(DCCS) joined us when he could. His group are involved in
a number of projects in the area, including
<a href=../TechInfo/Overview.html>TechnInfo</a>, Libraries, WAIS.
Tim sees the TechInfo system standing
alone until things have settled down in a few years: He guessed that in
10 years things might look more rational, and was in no rush to see
TechnInfo join any other projects.
Tim watches the migration path from MIT/LCS to the real Athena World
from a distance.
<p>Karen Sollins (MIT/LCS) joined us for some of the time.
<p>
From the University of Pennsilvania, there was a whole team
from the Data Comminications and Computing Services:
Mark Litwack organised the meeting, and had spent many months on
analysis of needs, and had drawn up a protocol specification
which we discussed in the afternoon.
(See <a href=W3AndArgo.html>notes on Argo</a>).
Linda ...... had already some experience attempting (!) to intsall
W3 software. John Hagan had a clear view of user needs and timescales for
the project. Jerzy Sliwinsky even broke into a vacation on Orchard Beach to
join us.
<p>
These groups had all been involved in an earlier attempt at homologation of
CWIS protocols, the "CWISP" group. This group had downed tools when
W3, WAIS, and Gopher came on the scene.
<p>
Our agenda was to make contact, and establish joint requirements list,
and decide how we could each contribute a solution meeting these requirements.
<h2>Argo requirements</h2>
In a broad sense, John gave the requirements as
<ul>
<li>Good Tools for providers
<li>A worldwide navigation system (Have I got this right, John?)
<li>Clients on all platforms
</ul>
He felt that UPenn's strengths lay predominatly in the first area, as
they did not have experience on many client platforms.
<p>
The Upenn team all showed great enthusiasm for W3, and said lots of
nice things about it. :-)
<p>
Things which came up as individual requirements for the system during the
meeting (and aren't in the current W3 world) included
<dl>
<dt>Form Filling
<dd>The Argo proposal dealt with the variety of server query functions
by alowing a generalized form language for specifying the query.
This obviously extends into the electronic data interchange (EDI) field...
<dt>Multiple formats
<dd>An example was the need to handle scanned data such as bus timetables
which are impossible to type in (or OCR) reliably.
<dt>Application Lauching
<dd>The Upenn team were very keen on this, seeing it as a major need
in their environment. They see many ad hoc scripts currently
being written to point users at available applications.
The scripts are sometimes quite complex, including for example
telnet logon though several gateways.
<dt>Complex interaction
<dd>Users had asked for a client which could handle, for example,
the purchase of a book from stores, including form filing,
and the return of the form with prices totalled for signature.
There was a feeling that this was going too far.
<dt>Client history
<dd>It would be neat for a client to keep a list of all the things
a user had EVER read, so that he could search within that domain.
Also of course the "seen" function identifies links to things seen before.
<dt>Client SW update
<dd>Should a server who knows that new client software is available
tell a client whoc has the old software?  This is important, probably
the only way to ensure updates occur. Client should be able to
reinstall the new version itself. Does this have to be part of the
protocol?
<dt>Forwarding
<dd>It is necessary for servers to be able to refer clients to
other servers, possibly as a function of the location of the client.
<dt>Native Interface
<dd>It is good to give a user an intuitive interface compatible with
his native browser (Mac Finder, etc). But is this powerful enough
for the whole net?
<dt>Self-contained client
<dd>Steve W: It is easier to sell a self-contained client which has
built-in handling of many data formats (a la Gopher)
than to sell something which must be configured.
</dl>

<h2>My Conclusions</h2>
Both CERN and UPenn need to get the next version out fast, by the end of this
year.  Our goals overlap very much. UPenn's technical input is very worthwhile,
and the sharing of work will be essential to get the functionality we all need.
This fits in with the W3 consortium idea, UPenn would be founding members
of the consortium.
<p>
Technically, my feeling was that we should separate the document format
infomation in the document from the access information stuff. This is
not just a technical decision, it is also a project management issue that
the two things must be decoupled and a "flexibility point" introduced
between them.
<p>
The forms idea is a very useful one, which should be either decoupled
from the hypertext or, ideally, made an extension of the hypertext format
so that tags in common are used. I would suggest that we look at an SGML
form of the forms syntax for acceptability in a wide community.
<p>
The address syntax for remote access is a tricky area, as it
goes from the basic UDI into a full query/scripting language without
a clear line drawable between them.
<p>
I suggest we draw the line in the following way. We need UDIs to encompass
everything which the current W3 handles for back-compatabiity.
I would not extend UDIs to contain telnet session scripts, so I would
suggest that we adopt a scripting language from argo which
will cover the telnet case as well as xlogin and launching of arbitrary
applications. This scripting language, if it can't be anything standard,
should be defined, made public, and a data format be defined for it,
and registered with MIME for example. I would suggest W3 migrate toward
use of such scripts for decribing telnet sessions.
<p>
The UDI will therefore describe just the address of an object in some
network namespace. It won't have complicated algorithms.
It won't contain SQL. We will allow it to contain the simple W3/WAIS
style text user input. Aything more complicated will have to go via
an intermediate (named) document. [I'm not sure that this is right.
I think that when a really cool script lnguage is developed which is
generally accepted and complete and everything, then we might
allow a special UDI which is an expression in that language, for
completelness. That will be "scripts under buttons" which people want
often, without intermediate files. In the mean time, we need more
experience of scripting language candidates before we allow people
to quote a bunch of script as a reference)].
<p>
The actual format of UDIs wil be discussed in a wider group than
this meeting (www-talk plus the ietf nir groups, basically).
<p>
There a few minor differences betwwen the "dip" access specifications
and UDIs as in W3 now, which we can iron out with time, but they
are minor.
<p>
We should separately check whether there are any things in the
"dip" document format which should be taken into HTML.
Like "expires" for example is a good one.  I'm not sure about icons
and portability.
<p>We should therefore end up with three items:
<ul>
<li>A scripting language for telnet sessions etc etc
<li>An enhanced HTML
<li>A form description language hopefully in SGML too
<li>Protocol extensions for the return of forms
</ul>
<h2>By the way...</h2>
<ul>
<li>Will W3 software accept a gopher address in a gateway definition?
(HTAccess.c)
<li>Karen had been talking to Lotus, who firmly believe that Lotus
Notes, with its Novel-based protocol, will take over the world...
<li>Jersy mentioned that "Express (?!) are doing format negotiation"
but I never caught up on that reference -- details, Jerzy?
<li>Steve said W3 and
<a href=../../People/CNI.html>CNI</a>
ought to talk.
</ul>

