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

Part of the record, but those who have pressing work, hit delete.

>David G. Durand wrote:
> 
> 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_.

Yes.  I think that is what I was saying to Jon.  Interoperability isn't 
guaranteed by XML.  To do that, we would have to do something similar 
to the MID or hardwire some linktypes with axiomatically defined 
behaviors.

> 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.

Ok.  Won't that eliminate a fairly large number of applications?

Netscape was bad HTML, soon became good HTML, then MS introduces 
Other HTML, and so it goes.  This is SGML application development 
as we know it in practically every SGML application.  Even the 
Federal government couldn't put the teeth in to prevent it in IETMs.

However, we know what the pathologies are... err... we know which 
fish keep coming up again and again.  We have the low-bottom dwelling 
catfish <font >, we have the fast barracuda <form   action=, etc.  I
guess 
what I see is that these babies are always with us and 
after ten years of trying, we don't seem to be able to make them 
go away.  So why not flag them, tag them, bag them, and offer 
alternatives in our software?  Put out a net then sort the catch later.
 
> 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_.

Within narrow limits, perhaps we can.  This depends on the requirements.
We knew what the objections to the gosubs, gotos, spawns, in MID were.
That is why they were optional.  But to meet the requirements which 
focused on interoperability, we couldn't think of a way that was 
easier to explain, simpler to user, and met the requirement.  It 
wasn't a theory issue.  The design was meant to make GUI behaviors 
as interoperable as possible.  All I can say is the language works.

Because you and I have covered this ground over and over again, 
perhaps people understand that there isn't a universal hypertext theory 
that will apply, or satisfy all cases.  It remains to be very 
specific about the cases XML will satisfy.  Again, we debate until 
the ERB decides, and we move on.  Making the business case is 
a different thread.  Yes, I am being contrary.  No, I won't stop.
Yes, it is easy to ignore this.  No, it won't go away.  Before 
we ask them to buy products, we have to be more clear than we have 
ever been about what XML makes possible and impossible.
 
> 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.

This is where we differ David.  My job is to be able to say that very 
precisely.  It isn't an exercise.  The agreements my customers make 
have implications that rattle up and down the carrier decks and 
through the halls of every major weapon systems vendor on the planet. 
I know that is "dramatic"; it is also, true.  I'm not tagging 
manuscripts from Rome.  I almost wish I were.  In truth, I am 
much more of a purist than it appears here because I have also 
done a lot of conversion and I know what a PIA variants are.
I also know we have strung large communities along for sometime 
with our proposals, and now they believe the Web applications 
are the answer to their problems.  Now, XML is offered to 
solve those problems but with totally different software.

It's a good idea, but a hard sale.
 
> >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.

Ok.  We are at an impasse on that.
 
> 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. 

There isn't the time.  We have been trying to do that for a decade and 
so far, most of the DTDs I know of have the pathologies I mention in 
one form or another.  We are not Italian aristocracy who can lock
ourselves 
up in a castle and wait while the plague rages outside our walls.
We are lowly software peddlars.  To sell our glasses of water, they 
must buy both kinds and drink.  Where there is thirst, they drink 
with or without the water filter.

> 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.

Integrated Open Hypermedia:  Bibliographic model.  It did not produce a 
design for a digital computer.  Poor Alan Turing, and Hopper, and 
Von Neumann, and so on did.  I can't sit here and say the Book Metaphor 
is imperfect, or that it doesn't work.  I can say that where we have 
developed hypermedia on the digital computer, lots of different 
solutions have been tried and do work.  Each has tradeoffs.  We 
are debating the tradeoffs.  Where we go Beyond The Book Metaphor, 
as I said some years ago, we are on new ground taking risks, making 
mistakes, and sometimes falling off the monkey tree.  We are learning.
 
> 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.

I do not disbelieve you.  I debate you until the bell rings.
I enjoy it.  As Charles said to you and Steve in Orlando some 
years ago while I was laying on the floor getting flu, "you're good."

But for today, we must help Tim and Steve finish the draft.  I've
said my piece.  It has been considered.  Time to move on.

I have to get back to designing a landscape for Europa. :-)

len

Received on Tuesday, 4 February 1997 15:07:53 UTC