CLIM mail archive
[Prev][Next][Index][Thread]

[jcma@reagan.ai.mit.edu: Re: EDI Without Formal Agreement]

Folks,

This is a snippet from the ietf-edi (electronic data exchange)
discussion.  There is a great opportunity for CLIM style presentation
technology, whether running in lisp or C++, for WWW and data exchange
standards.  The WWW community is large, growing fast, and highly
visible.  This is a way to get advanced interface ideas out into the
mainstream in a hurry.

My questions are:

1) Does anybody have a lisp-based HTTP server?

2) Does anybody have a lisp-based WWW browser?

3) Does anybody have a CLIM-like presentation system that runs in C or
C++?

Date: Thu, 13 Jan 1994 16:37 EST
Errors-To: admin.adm1.jdbracke@byugate.byu.edu
Reply-To: ietf-edi@byu.edu
Originator: ietf-edi@byu.edu
Sender: ietf-edi@byu.edu
Precedence: bulk
From: John C. Mallery <jcma@reagan.ai.mit.edu>
To: Multiple recipients of list <ietf-edi@byu.edu>
Subject: Re: EDI Without Formal Agreement
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas

    Date: Thu, 13 Jan 1994 13:27 EST
    From: Dave_Raggett <dsr@hplb.hpl.hp.com>

    >>  Have any of you considered using fill-out forms and the World Wide Web
    >>  for simple transactions?

    > Unfortunately, fill-out forms are a bit simplistic and
    > need to be extended by adding a presentation system
    > along the lines found in the Common Lisp Interface
    > Manager.

    As the editor of the HTML+ document spec I would very much like to
    know what features you see as missing. We are in the process of
    adding support for dynamic updates, and this will make it practical
    to make selections effect dependent fields, under control of
    the server.

In short, an extensible, typed system for presenting
and accepting input.  Typing the various aspects of
the interface makes life vastly easier as it enables
amazing amounts of code sharing.

    It would be a shame to miss the opportunity to blend EDI with
    developments going on in the web. What would it take for us to
    add support for basic EDI?

This is a moderately long story, so I shall summarize
below, and we can follow up as necessary.

    Dave Raggett,
    -----------------------------------------------------------------------------
    Hewlett Packard Laboratories,           +44 272 228046
    Bristol, England                        dsr@hplb.hpl.hp.com

Basically, you could start by replicating in C++ a
range of presentations types from the Common Lisp
Interface manager and add ones specifically useful to
WWW and EDI. Presentation types boil down to ways of
translating between the user interface and program
datatypes or datastructures or datafields, e.g.
integer, float, array, list, sequence, object-class,
image-type, ..... date, dollars, or basically whatever
you want.  In essence, each defines a parser and
presenter for the presentation type.  It is also
possible to have special translators that know how to
turn one presentation type into another, known as
presentation translators.  Command processors have
been written with presentation technology. So, this is
really very powerful and general stuff.

For closer inspection, you can FTP the CLIM spec from
cambridge.apple.com:/pub/clim/. There is also a
mailing list at clim@bbn.com, which is a good place to
ask about obtaining a manual.

For WWW/HTTP/HTML, the first thing to do is to use
ACCEPT-FROM-STRING and PRESENT-TO-STRING to structure
the read string field in the current forms interface
for WWW/HTTP/HTML.

Once that words, you can incrementally hair it up to
present graphics as well.

The big win all around, in our experience, is that by
having specialized translators that mediate all
interaction between the internal datatype and the
external presentation manipulated by the user, you can
guarantee syntactically correct input to your internal
programs, eliminating an important source of error.
With some semantic constraints between presentation
types, one can also reduce logical errors. (1-2-3 on
the user input).

This is rather handy for database systems and makes
the interface incredibly user-friendly as it cleanly
abstracts the code required to handle specific types
of input.

A further feature is a parser/presenter can execute an
arbitrarily complex function, (e.g., parse text and
return node in knowledge representation or generate
text from node in knowledge representation, which I
implemented for ny NLP system).  In sum, users can
incrementally extend the parsers and types as they see
fit.

For interactive, bootstrapped EDI, the servers/clients
would first need to exchange their presentation-type
definitions and their data schemas in a standard
language (e.g. safe-tcl).  The more shared conventions
there are on standard datatypes and standard
presentation types the easier this start-up can be.

If the various EDI translators happen to run
presentation systems, then it might be a matter of
negotiating the mapping between their presentation
types, since we assume that each can map input via
their presentation type into their data fields.

If the vocabulary of presentation types is well
designed, it may be possible to define most exchanged
presentation types in terms of a parsimonious
conventional set.

Anyway, I implemented a object-oriented datahandling
system with presentation translation between internal
data and the user in 1987 using a precursor of CLIM
and we have been quite happy with it.  Benjamin Renaud
(Benjamin@ai.mit.edu) is working on a thesis to
generalize it to, among other things, run over remote
protocols, e.g. HTTP, and exchange codebooks different
datasets.  The tough issues are going to be mismatches
in data ontologies requiring interpolation and
extrapolation.

We have been running a email server the uses
presentation types to implement forms since last
October (soon to be replaced with a vastly better
one).

So basically, there is little doubt that this kind of
technology can be applied here.  I think the main
limitation is that until now it has only be used by a
very small community.  If we had a reference
implementation in C running in HTTP servers, I suspect
it might find quite wide application.

John Mallery
Artificial Intelligence Laboratory, NE43-797
Massachusetts Institute of Technology
545 Technology Square
Cambridge, Massachusetts 02139-4301
Main Index | Thread Index