The Argo Protocol

The argo protocol comes of work started over 2 years ago at UPenn, culmination in a design, documentation, and presntations of the scheme. The thinking before that time was about "Information Systems" as applications, and about "Navigation Systems" which navigate betwen applications, the realisation that these could be one and the same thing being encapsulated in Argo.

There was at the meeting a discrepancy betwen the W3 and Argo views of the world. For example in Argo, data formats and protocols are trated similarly. The term "document" had a subtly different place in the scheme of things, and hence the ideas about naming and addressing were different.

To understand this from the W3 point of view, one must realise that the argo protocol came from a CWIS design which had originally been centralised, and was certainly authoritative. That is, the argo server was the authority on which one was to rely. All references to documents or sessions on other servers therefore go though an argo node in which all the means of access are descibed. (See example) This allows

The list of accesses to be changed if the target moves, and
The list of be quite complex, a document in itself.

The model then can be that all document references must be to argo documents, references to things using other protocols being passed though an argo forwarding document. This is a little totalitarian in concept. It assumes that argo UDIs will be more relible than pointers into other services. It also requires that for every external object there is a pointing argo object.

However, there is a lesson to be learned from the power found to be needed for the argo access language. There are hundreds of tags. Of these, a relatively small number are used in that which is equivalent to a UDI. The argo language includes syntax for:

Network address specification
Document description
Document
User input forms

The argo document is interpreted in many different ways. It is interpreted on the server ("if" and "include" tags) so as to prepare the result for the client. Here, all tags in the language which the client does not understand are omitted. This is an interesting model.

The argo is interpreted on the client, im the data acess mechanism, and then by the presentation tool.

The W3 team took the decision to separate these functions, and it seems to me that this would be wise with argo. The business of defining formats for multimedia documents is not something to get into lightly, and therefore not something to which to tie a protocol definition. The art then is to define a clean break between the two, in order to develop each very important aspect independently.

(This is especially necssary if either aspect is to attempt to parallel standardisation efforts in either field. Designing in distributed hypertext today means being in 3 fields at once: that is life.)

To be continued...