So, let's pick this up again: bibliographic references are *usually*
(in the "most common version" to use precisely your words)
pointers contained in one document that refer to a second document
with no third document involved, and your canonical counterexample
to the blanket statement is commentaries on the works of philosophers.
I am given to understand that this is a forum for programmers,
not philosophers or librarians.  But be that as it may, I have,
amazingly enough, actually read some commentaries on the works of
philosophers, and I still don't know what you are talking about.
The closest thing I can think of is where the commentator commenting
on the work of philosopher A makes reference to A's reference to
philosopher B.  (This, of course, can be and sometimes is carried
to ridiculous extremes where A comments on B's commentary of C's
discussion of D's ...)  But this doesn't seem to me like the "third
party" link that you were talking about, this is just a reference to
another reference, which you can do in HTML. So I think I'm still missing
something.  A real example would help a lot.

E.
---

Cheers,
M.

(If you literally mean that HTML doesn't compute things, then Common Lisp
doesn't compute things either.  *Programs* written in Common Lisp compute,
but Common Lisp itself does not.)

I'll say this again: what makes Web documents static from the point of
view of third parties who don't own or control the documents is not the
fact that they are written in HTML, it's the fact that they don't own or
control the document.  The document could be in Smalltalk but it will
still be a static document to you if you don't have write permission for it.

  I rest my case: You're clinically insane.

In a previous post, Erik states:

Did I understand this correctly?

So, assume for the sake of argument that there are web sites with the
contents of Norvig's PAIP and Graham's On Lisp, and you want to write
a page on certain sorts of macros.  You have the facility to define
some sort of session in which the reader will see the links you define.
You define links to arbitrary parts of Norvig's and Graham's books,
regardless of whether there's an <a> there or not.  You define links
between the two books that will be seen as long as the reader is in
that session, again at arbitrary places.  You put links in Graham's
book in arbitrary places, pointing to notes you've written on how
and why you disagree with Graham here.  You put a link in Norvig, pointing
to a more general macro you've written.

Having done all this, you package the whole thing up as Erik's Guide
to Macros, put it on your site, and I could surf over there and see
your material, Norvig's, and Graham's as you wish to present it.

  Yes, that, too.  The biblical chapters and verses arose for the
  purpose of the references.  Legal documents have their structure
  from the need to refer to individual sentences and items in lists.

| So, what you'd like also is an ability from document A to put a link
| in an arbitrary place in document B that goes to an arbitrary place
| in document C?

  Yes.

| (Obviously, this would have to be limited to a particular viewing of
| the documents; if it were possible to put arbitrary links in other
| people's pages in general, all pages on the Web would have multiple
| links to porn sites.)

  This is an important point.  Which links are active on a given page
  is controlled by the set of linking documents you have selected.
  The "viewing" is controlled by the browser, which knows about _your_
  linking preferences, glossaries, dictionaries, etc, and merges them
  with those contained in (or referenced) the document itself.

| Is that an adequate description of what you are complaining about?

  No.  I't s good start, however.

| Or are there other things you'd want to be able to do?

  Again as an example, I want to say, in a formalized way, "That part
  of document A contradicts that part of document B" and put it in a
  collection of comments on various documents on the Net.  When
  somebody picks up this collection of comments, they can visit the
  documents I have commented on in various ways and have an annotation
  box pop up in places where I had made such comments and go visit the
  other document to look at it.  However, this is not _too_ exciting.

  The exciting part is when the links themselves can be referenced,
  aggregated, etc.  That's when you _really_ need the ability to point
  to something and make it link to something else.

| I've been having trouble following the list of deficiencies, and
| would like to be sure I've got it.

  Think of it this way: If you are writing a novel, which would
  typically include dialog, you are not worrying about how to make
  irony come out right on your laser printer, because there's no point
  in making it visually distinct from any other text and there's no
  point in involving the printer unless you have a language to talk
  about the irony of a particular piece of text that could affect the
  printer's behavior.  You would, however, worry about how to express
  the irony in your own language.  The printer would simply render it
  in whatever way it usually renders text.  When people get stuck in
  the HTML world, they naturally complain about the pointlessness of
  talking about irony because there's no browser that would render
  <irony>foo</irony> differently from anything else, and it would look
  just like any other text.  If they _wanted_ the browser to render
  irony differently, they would simply write the low-level stuff that
  HTML defines to cause the browsers to change the rendering, but they
  would _still_ not think that _HTML_ supports irony.  HTML supports
  the mechanisms that allows something else entirely to express irony
  through its rendering-friendly language.  It is that something else
  that I'm interested in.  In the case of your novel and the laser
  printer, it's capturing the author's intent in a language able to
  talk about its own usasge, such as English.  In the case of HTML,
  it's whatever caused that particular "code" to be produced in the
  first place, ultimately _some_ authors' intent.

  Because HTML can do certain simple tricks, and because most people
  aren't aware of what they are doing, it is possible to conflate the
  expression with the intention, indeed common to do so among those
  who aren't and don't want to be educated.  This doesn't remove the
  intent.  It only means that some people will insist that if they can
  express it in HTML, there's no point in talking about the intent and
  other languages that would make it easier to talk about the intent.

  The fundamental deficiency in HTML is that it reduces hypertext and
  the intertwinedness of human communication to a question of how it
  is rendered and what happens when you click on it.  By giving the
  world a language in which numerous important concepts can no longer
  be expressed, these concepts are removed from our world.  When music
  was written down with notes, a lot of music that was very hard to
  write down with notes vanished, and music became note-friendly.
  When tasks are automated, the skills that went into the automation
  vanishes and only the skills required to keep the automated solution
  going remains.  When children learn to speak particular languages,
  their ability to speak other languages deteriorates and vanishes.

  HTML is to the browser what PostScript is to the laser printer.
  Normal people don't worry about PostScript when they want to employ
  irony in a dialog.  Normal people shouldn't worry about HTML when
  they want to make hypertext links.  They should think of what their
  _real_ needs are, and trust me, those needs are _not_ covered as
  such by HTML, but they can still be _expressed_ in HTML such that a
  browser can render it to the reader, just like PostScript does not
  cover the needs of an author as such, but most everything an author
  wants to say can be _expressed_ in PostScript and come out right.
  (And that which cannot be expressed in PostScript will have a
  natural tendency to become unwanted unless people change to a new
  language.)

  That is to say, everything I want _may_ be implemented with a chain
  of proxy servers that add their particular thing to the incoming
  HTML, just as I could add filters that hacked PostScript to get
  special effects on the laser printer.  The end result as it is given
  to the browser or laser printer is _still_ HTML or PostScript,
  respectively, but neither the HTML nor the PostScript were created
  to do what the proxy servers and filters have done _to_ them.  It is
  not productive to argue that "it's just HTML!  HTML can do it all!"
  when the software that produces the HTML is driven by so much more
  input than whatever generated the original HTML _or_ the browser,
  and which simply tries to teach the browser how to do things HTML
  _can't_ do on its own.  Which means that whether it is done by a
  chain of proxy servers or a smarter browser that understands a
  _richer_ language than HTML is immaterial, but you still can't get a
  browser that only understands HTML to do any of this stuff without
  the proxy servers in between.  For instance, CSS may be employed to
  change the rendering of an HTML document, and CSS may be provided by
  the user to override a document's rendering.  The HTML may contain a
  reference to some CSS that instructs the browser on what to do, but
  that still doesn't give HTML the credit for the rendering.

  To put it in yet another way: What I want the browser to do, is
  accept input from a number of sources, merge them, and produce a
  synthetical document that reflects decisions that none of the
  sources individually can know about, because they rest with the
  reader.  To achieve this without the necessary languages to describe
  relationships _between_ (other) documents is so cumbersome that it
  is effectively removed from the wish list to begin with.  (Imagine
  setting up a chain of numerous proxy services for each of the
  documents you want to look at -- you can't even click on links,
  anymore, because you may want to select another linking document.)

  I really hope this helps.

--

        Now I'm using a html preprocessor for these purposes, but a
markup language implemented in Common Lisp (or scheme) that would let
you use all the lisp tools to handle the data and latter render to
sgml would be much better...

Thank you,
John

(a) Biblical verses are quoted to support one side or another of an argument.
Sometimes only a fragment of the verse is quoted, and you can't understand how
the verse helps the arguer's case unless you read the entire verse in context.

(b) Because of the free-associative structure of the text, and because many
legal arguments in the Talmud do not end in a decisive victory for one side or
the other, it's hard (even if you know the source language) to simply pick up a
volume of Talmud, read a few pages of discussion, and walk away knowing the
answer to some legal question.  Some medieval commentators (such as Maimonides)
wrote easier-to-read legal digests, based on the Talmud.

Contemporary printed editions of the Talmud, therefore, put diacritical marks in
the text to indicate (a) Biblical quotations, and (b) statements that eventually
became accepted as binding Jewish law.  For each of these diacritical marks,
notes elsewhere on the page indicate (a) the book and chapter cited, and (b) the
relevant chapters and sections in standard digests of Jewish law.

Now, go read up about penguins and ostriches.  And rhetoric.

  A third-party link is a link that expresses a connection between
  (a certain part of) a document A and (a certain part of) a document
  B, that is contain in a document C, with A, B and C being pair-wise
  unequal.

Now, without resorting to any program or process, how would you
represent this connection using HTML?

My contention is that you will find it impossible to directly express
said connection in HTML.

Just like most machine languages are unable to _express_ the concept
of a function call directly, HTML is unable to express this concept
directly.  This doesn't mean that it is impossible to _implement_ the
concept of a functions call in machine language (usually using a
combination of stack accessing and manipulation instructions, register
loading and storing and jump/call instructions),  just as it is not
impossible to _implement_ third party-links using HTML (usually via
the use of additional processes).  But that is beside the point, or
otherwise we'd all be programming in machine language, which we
aren't, and for good reasons, since expressive power is what counts,
both with programming languages, and even more so with document
description languages.

But I'm merely echoing things (and doing so poorly, I suspect) that
Erik has already pointed out...

Regs, Pierre.

Attempted summary of a very large snipped part:
The problem is not HTML, but the fact that HTML is very basic.
It is hard to think of doing some of these things in HTML.
Similarly, Intel machine language is not a problem, but it is
a good thing that there are compilers for other languages.
It is possible for a Lisp programmer to do things that are very
difficult for an assembly language programmer, and more specifically
is likely to think of things that an assembly language programmer
would not.

Therefore, it would be possible to write a real hypertext language
that would process numerous things and deliver the result to the
browser in HTML, much as it is possible to write a Lisp program and
compile it.  This has not yet become mainstream because most people
don't see the desirability, much as most assembly language programmers
would not see the desirability of being able to write functions that work
with data types to be determined later.

Is this a reasonable summary of what you're saying?  (I do not think
that either of us is stupid, or inept in the use of the English language,
so I figure that this has to be potentially difficult concepts to convey.)

        You could have the equivalent of a sgml page coded as a big
lisp list.  Not only you have a simple and easy to parse syntax
(compare this with sgml), but you would have parts that are
dynamically generated (thus removing the need for an html
pre-processor --see my previous post) but you would have all the Lisp
tools availlable to modify and trnasform this text.

        Think about how much work you would need to design a
tree-walker in Lisp to process this list in order to render the text
into rtf, html, etc...  Now think about doing the same thing to an
sgml document...

        I really think that sgml is way too complex for the rather
simple goals it achieves.  

  I'm glad you two have found each other, but this is not a good place
  for intermoron romanticism.  Please take it to personal e-mail, at
  least to _contain_ the vileness of your behaviorial characteristics.

  If you ever recover, please consider less obsessing with me (or
  anyone else for that matter) as a _person_ and start on the wondrous
  journey of discovery that you experience when you listen to ideas
  and _what_ people are saying, rather than primarily or only _who_.

  Yes, but also including your own comments on things you had read,
  other people's comments, and probably news wires and mailing lists
  that supplied interrelationships in the form of third-party links.

| So I could write something like "These links of Naggum to Norvig..."
| or compare the Naggum and Pitman links?

  Yes.

| Attempted summary of a very large snipped part:
| The problem is not HTML, but the fact that HTML is very basic.
| It is hard to think of doing some of these things in HTML.
| Similarly, Intel machine language is not a problem, but it is
| a good thing that there are compilers for other languages.
| It is possible for a Lisp programmer to do things that are very
| difficult for an assembly language programmer, and more specifically
| is likely to think of things that an assembly language programmer
| would not.

  A compiler is a also good starting point for a comparison, but I
  tend to think of HTML as the PostScript of real hypertext -- the
  language of the renderer.  It would be possible, but fairly time
  consuming and very difficult, to write anything directly in
  PostScript, so people prefer markup languages like LaTeX or SGML
  that "compile" to PostScript or WYSIWYG tools that constantly
  recompute the rendering.

  Note, however, that a compiler is still limited as a comparison to a
  fixed number of source files.  The crucial element in my argument
  against HTML is that there is no way to "load" third-party links or
  rules into the rendering environment from other documents.  At least
  PostScript has that -- you can download functions and modify the
  printer's behavior.  None of the "dynamic" features smacked on top
  of HTML manage to get any of this right.

| Therefore, it would be possible to write a real hypertext language
| that would process numerous things and deliver the result to the
| browser in HTML, much as it is possible to write a Lisp program and
| compile it.

  Yes, _provided_ that it is done sufficiently close to the reader
  that the _reader's_ experiences and context can influence the HTML
  that the browser sees and displays.  This requires _very_ powerful
  proxy servers and a "visual" recognition of the HTML that is being
  transmitted from various places.

| This has not yet become mainstream because most people don't see the
| desirability, much as most assembly language programmers would not
| see the desirability of being able to write functions that work with
| data types to be determined later.

  I think it is not yet mainstream because people _fear_ hypertext
  before they know how to navigate in it -- and with good cause, too.
  The navigation problem on the Net is basically unsolved, but tools
  that could remember and deal with your own set of links would help a
  lot, and those would have to be maintained as third-party links in a
  sort of "active history", able to answer the question "now, what did
  I come here to look for?", which is both unasked and unanswered
  today.  But convincing people that something conceptually more
  complex is a simplifier is very hard marketing work.  (Just ask the
  Lisp vendors. :)

| Is this a reasonable summary of what you're saying?  (I do not think
| that either of us is stupid, or inept in the use of the English
| language, so I figure that this has to be potentially difficult
| concepts to convey.)

  FWIW, I'm pleased with your understanding of what I've been trying
  to explain for years with admittedly limited success (hence my "I
  don't have the patience for this" which was rudely overruled :).

  After spending about 6 years with SGML, and in the process becoming
  an international authority, I came to conclude that the complexity
  of SGML qua language outweighs its benefits even when applied very
  carefully and intelligently, and that never happened because people
  didn't really understand what the simple goals were.  I considered
  this fairly tragic at the time I decided to quit SGML altogether.
  (And "improvements" like XML actually make things a lot worse.)

  As for SGML and Lisp: I wrote a complete SGML parser in Emacs Lisp
  in 1990 and had a lot of fun with it, but it was very hard for other
  people to use for some reason.  When I was encouraged to speak about
  it, one of the forefigures in the SGML world commented "that's great
  -- for you and the other two guys who know Lisp" and ridiculing Lisp
  solutions became de rigeur in the SGML community, even though people
  struggled with problems that various Lisp solutions had solved.

My impression of XML so far is that the ideas behind it seem sensible,
but that several of the applications I've seen do little more than
wasting enormous amount of bytes (And then I'm not basically thinking
of the sick documents you get out of Office 2000, but rather the use
of XML-based formats for purposes where size and quick parsability
really counts, for instance "internet call data record" formats).

<meta name=associated-links content="LINKA LINKB">
<a href=... REL="LINKA">...</a>
<a href=... REL="LINKB">...</a>

Let me try to speed up the discussion by anticipating some objections.

Objection: This is not legal HTML.
Answer: Yes it is.  Read section 5.2.5 and 5.7.3 of RFC 1866 carefully.

Objection: Browsers don't know what to do this this tag.
Answer: Of course they don't.  They don't know that to do with XLink
and HiTime and all these other schemes that are floating around either.
That's my whole point.  In order for *any* of these languages to do
*anything* useful you have to write a *program* that knows how to do
something useful with them.  This is tautological.  There are things
that current browsers can't do.  But to assign the cause of these
shortcomings to HTML is IMO, to borrow Erik's phrase, obviously wrong.
The deficiency is not in HTML, it's in the currently available crop of
HTML user agents.

Its just as important how things are connected as what is connected.  When
one is learning how things are connected are probably more important because
what is connected are just statements (some true or some false).  It more
important to pass on how to learn (connections), to learn from those who
have gone before and be able to validate what you have learned.

On Windows, programs can hook into the browser at a very deep level,
and there are all sorts of companies that add all sorts of links and
text to the HTML in your browser, from reverse links, chat, and
glossaries to comparative shopping.

If you are a web site author, you can also choose to let people do
things with your pages like chatting, adding links, adding comments,
editing the pages, and rating.  Web rings provide another way of
adding links to pages, and Wikis provide full, automatic,
bidirectional hyperlinking.

For just a few links, look at:

http://crit.org/
http://www.alexa.com/
http://www.udanax.com/
http://TWiki.SourceForge.net/cgi-bin/view/Main/WebHome
http://www.webring.com/

The current level of usage of such techniques is likely more a
reflection of demand for them and scaling issues than any problems
implementing them based on HTML.