[Prev][Next][Index][Thread]

Re: Relationship Taxonomy Questions



At 1:18 PM 1/24/97, Len Bullard wrote:
>> >Yes, and VRML has done both already.  You should study it and
>> >understand what frameworks are, how they work, and why they
>> >work that way.  Now.  Today.  Not ten years from now.
>>
>> Well, I could tell you to look at the EBT software, and see how
>> reprogrammable link semantics work: "Now.  Today.  Not ten years from now."
>
>I have.  It is SGML plus a proprietary programming language with a
>pricey seat cost.  Last I looked, it was also a "holy scroller" and
>that is not a very good way to do hypermedia where enforced sequence
>and single-screen display per procedure is a requirement.  It is
>also hard on the eyes.   But, in the card sharks vs holy scroller
>debates, there is not much to be learned anymore.  I guess should we
>make our applications a debating point unless we illustrate a
>technique we wish to have.  Trying to get the world to
>"Standardize" on a proprietary application is an ancient and
>oft used tactic.  So far, it is making John Warnock rich as Croesus.

I was not suggesting that we adopt EBT technology (as if they would give it
to us for free distrivution over the web!). I was observing that the
"impossible to achieve" indeirection that you keep slamming has been
implemented since day one of EBT's product line -- and that includes, I
think, the first version, written by two people in a very small office in
about 6 months (If I have the history right).

The "issue" of link-rendering-style indirection being hard to implement is
simply a non-issue.

  If we provide example DTDs and style-sheets, it's not hard to learn,
either. You start with XML w/ an extended HTML DTD, and as you grow, you
can learn how to use the indirection to your advantage.

>> A lot of us are saying that behavioral indirection (Stylesheet may be a
>> confusing term) is a good idea for linking as well as for markup. You've
>> made no coherent argument yet, as to why that might not be true.
>
>I am not saying that it isn't.  I am saying that in some
>cases it isn't the best way.

Yes, but it's always possible to specify behavior if you have use
delcarative markup and indirection together, but it is not easy to get
delcarative behavior it you don't have that critical hook in place.

So, you have still to show that there's any reason _not_ to indirect. It's
implementable, and it loses you no requirements that you have made.

> If I want to specify that
>the state of this container is kept, thrown away, or irrelevant
>when traversing a link into a new space, I need to be able
>to specify that.

And  with an indirected style sheet you can specify that, without binding
others to that behavior when it doesn't make sense.

>  You seem to be saying I never want to
>say that in the content on the link.  I am saying such division of
>content
>from behavior in many cases is not performance-worthy
>regardless of purity tests.

The only response I have is not polite. This is simply not true. A single
hashtable lookup to fetch the script before execution is not a serious
performance penalty, unless you are still working on vacuum
tube-technology. I do assume that you're not, right?

>I am saying that all of the types of behvavior
>you want so far in linking come down to gosub/goto/spawn.

I don't agree, but we don't need to discuss behavior yet, though we
certainyl must define it before the whole process is done. This whole
discussion is what it would have been like if had been arguing about
typeface specification while defining XML -- irrelevant, but distracting,
because the red-herring claim that behavior can't be specified without
munging up the document gets people riled.

>> And personally I think the example of EBT's document display software is a
>> lot more relevant than VRML's budget simulation software.
>
>This is exactly the way HTML came
>into being.  Folks looked down their nose at the obvious solutions
>in favor of ones too strange for human understanding.  It worked
>until a certain group of kids chose to ignore their elders.
>It made a mess too, but change is messy.

This is an interesting revisionist, and rather hopelessly false view of the
history. If you read the literature you can actually see that the Hypertext
community's insitence on creating systems that could guarantee that links
would not break was the real problem. Tim said let'em break, and a
distributed database problem became a social problem. Big win.

>Very exciting things in communication, representation, and
>presentation are going on in VRML.  So far, XML
>is a rehash of style and graphs with arcs and circles.  Not
>useless, but not advanced.  HTML ++.

Maybe, but all I've seen is stuff that looks like computer graphics final
projects from when I was an undergraduate.  Anyway, we're talking about
documents. Text may not be as sexy, but the proven value is far, far,
greater over a 5,000 year history. So pardon me if post-verbal
communication makes me yawn.

>This is fun, but we have exhausted the topic.  I did not propose
>to put behavior in content in all cases.  I proposed that there is
>utility in
>recognizing that the purity of markup is not the highest goal.

Well, I'm afraid that you have still failed to make that case, as the "pure
approach" offers reusability that the other one does not, while the other
approach can be easily implemented in a "pure world". So where's the
utility in artificially limiting your capabilities and simultaneously
losing the proven benefits of generic markup?

>If you look hard at the MID work, you
>will find every punt possible on that approach.  If I appear
>to be defending it ferociously, it is because too many
>eagerly dismiss the work of others without first
>spending the time understanding the requirements or the gestalt
>in which it spawned or the good ideas it provides.

When it's appropriate to discuss presentation semantics, we should look at
it. I still contend that the presentation issues are an irrelevant
distraction at this point in time.

   -- 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                    \__________________________



Follow-Ups: