Argo etc

I had an all-day meeting with a number of people who had very kindly flown in.

From Cornell University there was Steve Worona. Steve had a lot of useful input, playing devil's advocate in querying the common assuptions of the UPenn and W3 teams.

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 TechnInfo, 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.

Karen Sollins (MIT/LCS) joined us for some of the time.

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 notes on Argo). 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.

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.

Our agenda was to make contact, and establish joint requirements list, and decide how we could each contribute a solution meeting these requirements.

Techninfo Gateway

While we wer looking at Viola running at MIT, it turned out that Linda Murphy had a Gopher/Techinfo gateway running already on her desktop workstaion. This provides access to all known Techninfo servers as a Gopher tree. Linda stressed that the gateway was not a solid service, and would stop any time she wanted it to or her workstation was not up. However, it is a good peice of work, and good to know that the techinfo world is in fact on the web. If there is a lot of demand for it, I'm sure Linda could set up a more permanent server somewhere.

Argo requirements

In a broad sense, John gave the requirements as He felt that UPenn's strengths lay predominatly in the first area, as they did not have experience on many client platforms.

The Upenn team all showed great enthusiasm for W3, and said lots of nice things about it. :-)

Things which came up as individual requirements for the system during the meeting (and aren't in the current W3 world) included

Form Filling
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...
Multiple formats
An example was the need to handle scanned data such as bus timetables which are impossible to type in (or OCR) reliably.
Application Lauching
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.
Complex interaction
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.
Client history
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.
Client SW update
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?
Forwarding
It is necessary for servers to be able to refer clients to other servers, possibly as a function of the location of the client.
Native Interface
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?
Self-contained client
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.

My Conclusions

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.

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.

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.

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.

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.

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)].

The actual format of UDIs wil be discussed in a wider group than this meeting (www-talk plus the ietf nir groups, basically).

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.

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.

We should therefore end up with three items:

By the way...