Re: Web neurons

Len Bullard (cbullard@hiwaay.net)
Mon, 27 May 1996 10:26:57 -0500


Date: Mon, 27 May 1996 10:26:57 -0500
Message-Id: <9605271526.AA23037@fly.HiWAAY.net>
To: john@eco.powernet.co.uk (John Middlemas)
From: cbullard@hiwaay.net (Len Bullard)
Subject: RE: Web neurons
Cc: "hyper-theory@math.byu.edu" <hyper-theory@math.byu.edu>,


>>Check out http://navycals.dt.navy.mil/mid.html and look for a language
>>called Metafile for Interactive Documents of MID. 
>
>I had a quick look at this, it is quite involved, but seems promising.

Not for the timid, for sure.

>>It uses chains of infoContainers as state machines for navigation
>>of database content.  The link traversals are gosub, goto, spawn and get.
>
>I think the database content you refer to is the pages out of a technical
>manual. 

Could be any database for which a handler exists.  I've been writing
an example for the xeno declaration, and it essentially is just a function
declaration, function, and named arguments of type string.

>The goto looked like my FIRE command at first but there doesn't seem
>to be the possibility of transferring INPUTS from one page to another.

That would be a xeno, I think, although since this is an SGML/HyTime
application, one could also statically define values for notation declarations
or HyTime notlocs (notation locations).  This is not a nice solution
because they are static, so xenos would be preferred.

> Also I am not sure if MID could run a page
>purely for code reasons without displaying it. This too would be essential
>because fast code only, programming Webs, must be integrated with everyday
>browsing.  

Good question.  I think a MID wouldn't be the best tool for that. 
It was designed to encode logical navigation, so it is very tied
to the widget containers.

>What is the equivalent of the URL in MID?

A HyTime clink, ilink, etc.   MID links don't work like
URLs.   A URL is simply a uni-driectional inlined link
with some caveats for relative addressing.  In MID,
the links can be stored separately, on in pools,
or local.  These are HyTime link and location
architectural forms which are subclassed to
create the location types you need.  A URL is
roughly an SGML entity 

<!ENTITY myTarget  SYSTEM "/foo/myrurl.txt" >

It requires another location element type such
as a nameloc which contains the entity name myTarget.
The nameloc is refered to by some link type
which could be the equivalent of an anchor.
SGML rules for names and IDs force indirection.
If you want a URL, you can use a HyTime notlink
(notation link) which allows you to do what a URL
does directly.

>>The links can be strongly typed and are n-way.  These links
>>can be powerful because semantics can be assigned and
>>used in functions, expressions, and xenoforms
>>for calls to externals.   
>
>Don't understand all this but calls to externals would not be necessary if
>networks of richly connected Web neurons with small amounts of standard
>internal code were used instead. Any external function could be performed by
>these, which are also capable of modelling any n-dimensional curved space
>(IMHO). 

Ok.  I know a bit about neurons and petri-nets, etc, but I
don't quite get that.  Is this similar at all to the kind of thing
that happens when a Netscape/JavaScript onLoad function
fires?  Can your network be simulated that way?

>What I am really saying is that I believe the concept of Web neurons (which
>is actually very simple) could be applied at all levels of computing, from
>the way we build the hardware right up to the top application level and
>indeed it is installed at the highest level of all - the brain. 

Sounds ambitious.  Just a bit of philosophy:  everyone I've
seen who starts out with the "if we just start over and do it
right approach" seems to hit a hard wall of legacy systems
and "not invented here".  In other words, the tiger is already
in motion, so take care to get a good grip on the fur. :-)

>If one simple system is used throughout then the average man might just
>understand computers (and even be able to program them).

>>It was created as a client language
>>for long lifecycle behaviors (e.g, technical information).
>>MID was designed to be interpreted or used as an
>>intermediate transport language.  It is verbose but
>>it was meant to be human readable and reasonable
>>to teach to humans. 
>
>I think it has possibilities, and seems more advanced than HTML. It doesn't
>really matter how you do it as long as there are no dead end blocks to stop
>it working. I don't think there are with HTML. The biggest problem may be
>altering server URL handler software.

Yes.  Well, we didn't have HTML or the WWW in mind
when we designed it.  The dead ends with HTML probably
start in using a declarative root language.  Things can
get pretty complicated in that tree after a while.   The HTML
model has limits that begin to show as more folks try
to add more functionality and cannot agree on it.  HTML
should be an architecture, not a DTD.

>>Libraries can be built using SGML general entities 
>>and catalogs.  It is ISO 8879 and ISO 10744 conforming.  
>>I realize that cuts little ice in the Web worlds, but this 
>>wasn't designed for the web or HTTP although it could 
>>work in that environment.  Three working prototypes exist with
>>the last built under the MS MFC.   The US Navy designed
>>it but it is an open specification.
>
>Is anybody planning to bring it to the Web?

Maybe.  It has been discussed, but more in terms
of bringing it to the Internet or other networks
not used by the public.  The WWW is a subsystem
of the Internet.   Users of HTML may not be the
same users as MID.  For one, MID is harder to do
unless an authoring tool is built for it.  That is
quite easy to build.   Also, since MID is solidly
built over ISO standards, some IETF'rs will
reject it out of hand.  And so it goes.
The choice of a protocol for MIDs is really
open at the moment.  I don't know if HTTP/MIME
is what is needed.  It has been suggested
that we use raw TCP/IP sockets, but this is not
my area of expertise, so I defer on that.

Nothing stops one from making a MID
system that works across TCP/IP.  It
will be done more than likely, but that is
something that depends on customer needs.
If I were doing it, I would target it at enterprise
applications.  For that, it would be quite good
in the same way that Visual Basic is.

cheers, 

len bullard

http://fly.hiwaay.net/~cbullard/