|
<![CDATA[
Date: Wed, 29 May 1996 22:42:45 -1000
From: Art Pollard <pollarda@hawaii.edu>
X-Sender: pollarda@uhunix4
To: John Middlemas <john@eco.powernet.co.uk>
cc: "C. Len Bullard" <cbullard@hiwaay.net>, connolly@w3.org,
hyper-theory@math.byu.edu, preece@predator.urbana.mcd.mot.com,
www-html@w3.org
Subject: Re: HTML is declarative on purpose [was: Web neurons ]
X-UIDL: 833491981.000
>From john@eco.powernet.co.ukWed May 29 22:15:06 1996
Date: Wed, 29 May 1996 16:50:15 -1000
From: John Middlemas <john@eco.powernet.co.uk>
To: "C. Len Bullard" <cbullard@hiwaay.net>
Cc: connolly@w3.org, hyper-theory@math.byu.edu,
preece@predator.urbana.mcd.mot.com, www-html@w3.org
Subject: Re: HTML is declarative on purpose [was: Web neurons ]
> Yes, there is no way the indexer could easily sort out the vast number of
> different database formats, applets etc. So what is the answer here? The
> whole system is a bloody mess, in need of a severe amount of pruning and a
> major rethink.
There is a system called Essense that does just this. Basically, all it
is is a bunch of filters. Each filter is tuned to a specific data type.
The basic engine then only needs to be able to recognize the various
datatypes and to then call the correct filter.
This gets around a good portion of the problems. However, I don't think
that it really solves the problem -- and I am not convinced that it is
solvable. However, I do think that HTML has a long way to go and that it
can be improved greatly and that if we can find / design a system that
deals with these problems we will be way ahead. (Of course, getting the
world to adopt the solution is a different matter.)
> To recap then - HTML is declarative on purpose i.e. to avoid indexing
> problems. But there still are indexing problems even so! - as Scott points
> out. So then there is no reason HTML should not progress to turing
> completeness.
Well, I wouldn't go so far as to say that. HTML is as it is because it
was based on SGML. SGML is as it is because people were looking for a
markup solution for text for publication. (i.e., not hypertext systems.)
Even now, HTML has started to move away from the "true ideal" of SGML
which is to separate content from presentation. (Yes, I realize that SGML
can be used to develop markup systems that don't meet this concept but,
that is besides the point.) This move away from the ideal of content
separated from presentation was done primarily by Netscape with all of its
Netscapeisms. However, the very fact that they are used even though they
bastardize and "ideal" just goes to show that there is a need. In short,
the world has adopted HTML as it is not to benifit search engines or any
other technology per se but simply because it was available and suited the
purpose, wasn't proprietary and had free tools. Now, we will have to live
with the ramifications of that decision good or bad.
> HTML is already relentlessly extended - just a few more shouldn't make
> much difference. I don't think you need many extensions to get turing
> completeness. As I understand Turing machines (HTML analogy), you would
> mainly need the ability to automatically m ove data between pages, given
> that the HTML page is the building block (analogy with turing tape
> placeholder) of the system. Also, you would need a simple bit of data
> processing in each page (analogy with turing program).
> You could define a new Web language with logic flow etc, but why
> complicate by splitting the logic flow commands from the declarative? For
> example even BASIC includes GOSUB's and PRINT statements (but has no
> hyperlinking, therefore is rubbish).
Yes, this is a good idea. I'd be interested to see what thoughts people
have on the subject. However, it must be realized that anything short of
C/C++ hybridized with say lisp is going to keep people wanting. Basic
for example is a decent language -- for what it can do. (Well sort of.)
However, people complain not so much about its syntax or structure but
its limitations. As soon as there is a programming language for
hypertext, you open this can of worms. However, that _does_not_mean_
that there shouldn't be one -- just that people will always be wanting to
do more and more with it.
>>Applets are a different issue from JavaScript.
>>An applet is a parameterized call to an
>>external handler. The indexing engine
>>shouldn't look in that box except to note
>>that a call exists and perhaps what it
>>calls if that is useful indexable information.
>You wouldn't need applets if HTML was improved.
Yes, you probably would. As soon as you give people enough power,
to do simple things, they will be wanting to program whole database
systems in it. There will always be a need to be able to interface
an external program with the presentation of data. This is part of
the function an aplet provides.
Of course, if there were a decent language which had control structures
in it, a lot of the simple things applets are used for would then be
done through this language.
-Art
Art Pollard | First there was World War I, next came
PollardA@Hawaii.Edu | World War II, last came the World War Web.
Moderator for Comp.Theory.Info-Retrieval
]]>
|
John Middlemas
hyper-theory@math.byu.edu
John Middlemas
Author profile
Mail him