Re: 1.c-d: Define a Link Processor and Communicate With It? (repost)

At 10:41 AM 2/4/97, Len Bullard wrote:
>The basic understandings are HTML and the URL approach.  We can't
>assume the former.  What understandings will we assume?  It is
>because they extend HTML without agreements (violate the contract) and
>use the market
>to work out the differences that they have interoperation problems
>now.  So far, we can only assume portability based on syntax.

We cannot guarantee arbitrary interoperability without losing the power of
XML (making your own description language). But that makes it incumbent on
us to clearly draw a line about what our linking primitives _do_ and _don't
do_.

If we say use indirection, then we are providing a powerful well-structured
way to do things such that people who don't do it cannot claim to be
compatible with our linking, or they have created a buggy implementation.
Just as Netscape-style HTML was "bad" HTML to an original Mosaic user.

If we also provide a separate, but powerful execution spec to complement
our linking, I hope that people will not make such agreements, but we
cannot prevent that. However, it doesn't stop us from specifying a
machanism that _will interoperate_.

We can't control people, but we can define the terms for a social agreement
(Extended Hyperlinking). Whether the baby will live or die afterwards is
something we cannot tell.

>HTML includes ACTION="post" | "get".  Can we use XML hyperlinking
>to build controls with predictable behaviors unless we agree on the
>behaviors?  We can agree on indirection although they may still
>elect not to do that with all of the implied compromises to
>portability.  How do we agree on what we indirect to?  As soon as
>controls are interlaced with data, we have this conflict of interest.

I think we should not put ACTION= into the our linking spec, though we
might be able to define a processing spec that will let people implement it
if that's what they need.

Just because HTML has muddied the waters, we don't have to drink mud. We
can let the glass settle out into two nice clear layers of drinkable
content water, and muddy execution specs. Another reason to separate
execution specs from linking and document markup is that linking and markup
have (in various forms) centuries of analytic and practical work underlying
them, while computer display has a very short, incredibly variegated
history, with few "tried and true" solutions.

If you disbelieve me on the history of hyperlinking, check out a Talmud,
annotated bible, or scholarly critical edition, to pick 3 well-worn
examples.

  -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Tuesday, 4 February 1997 13:15:45 UTC