Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcvax!ukc!its63b!hwcs!hci!gordon
From: gordon@hci.hw.ac.uk (Gordon Howell)
Newsgroups: comp.databases,comp.cog-eng
Subject: Re: Human Interfaces to Database Systems
Message-ID: <123@glenlivet.hci.hw.ac.uk>
Date: Wed, 16-Sep-87 12:02:57 EDT
Article-I.D.: glenlive.123
Posted: Wed Sep 16 12:02:57 1987
Date-Received: Sat, 19-Sep-87 18:51:18 EDT
References: <1275@geac.UUCP> <120@glenlivet.hci.hw.ac.uk>
Organization: Scottish HCI Centre
Lines: 46
Xref: mnetor comp.databases:495 comp.cog-eng:245
In-reply-to: gilbert@hci.hw.ac.uk's message of 14 Sep 87 16:36:37 GMT

Posting-Front-End: GNU Emacs 18.41.4 of Fri Sep  4 1987 on glenlivet (berkeley-unix)



In article <120@glenlivet.hci.hw.ac.uk> gilbert@hci.hw.ac.uk (Gilbert Cockton) writes:

   In article <1275@geac.UUCP> david@geac.UUCP (David Haynes) writes:
   >
   >Minimal requirements would be:
   >
   >	There is a clear division between the presentation and
   >	application interfaces.

   Sure you want this? Field validation by definition is
   application-dependent. Perhaps what you want is a good two-way
   interface between the forms manager and the back-end database. Most UI
   software only handles the UI->back-end mappings, making good semantic
   feedback impossible.

Certainly field validation is application-dependent, but I would
suggest that there is a limited set of field validation operations
that are ever used in practice.  Simply implementing these as part of
your forms description; and providing a call-back mechanism for
oddball validation requirements might solve your objection as well as
provide complete separability.

   P.S. - a clear division needs bridging - what's your bridge going to
	  be? If you want to talk to someone, you need to know something
	  about them.  Strict separability only matters for prototyping,
	  customisation and multiple UIs. Otherwise the cost of
	  separability is not balanced by any major gains.
Except the possible gain of being able to match company X's DBMS to
company Y's forms package.  Then the problem devolves :-) into a data
flow standardization question...  (Or we can all argue the definition
of "strict separability" which is the same problem in different clothes.)

I agree that right now I'd prefer *working* tools; but I think our goal
should be to provide UI software architectures that allow us to pick
the best tool for our application ("best" being defined by useability,
cost, politics or however individual organizations like to pick
'em...)  Is this architecture possible?  I'm banking on it...

[I use the term "forms", but understand that this can really be any
db interaction technique...]

-- 
Gordon Howell					gordon@hci.hw.ac.uk
Scottish Centre for Human Computer Interaction
Edinburgh, Scotland