Re: Relationship Taxonomy Questions

Please note in this discussion, I am not advocating adopting 
the MID.  I am taking a position that:

1.  It isn't necessary to have normative relationship types.
So far, I think we all agree on that.

2.  There are ways to use primitive behaviors and scripted 
behaviors in generalized markup to the advantage of the 
user.  That this is the best way is a matter of requirements 
and these cannot be generalized.  Furthermore, because 
existing systems (VRML, HTML, MID, HyperCard, etc) use 
these approaches, a metalanguage that cannot represent them or 
by fiat declines to represent them is flawed and untenable.

David G. Durand wrote:

> Let's see, we have talked about element types, and types for the individual
> endpoints of the multi-way links. So, that's more complex than what you
> list. We have discussed what forms of adress designation we want to support
> (with little disagreement about goals, only details).

Nope.  Go back and read the MID documentation.  I'll read the 
TEI Extended Pointers document. Then maybe we can chat.

> This is more than saying "you've got a DTD, make links!" I suspect you may
> have a bit more in mind here -- since in the rest of your argument you are
> aguing for less abstraction so that links will have to specified in terms
> of behaviors. 

Nope:  can be.  In effect, if a hyperlink is static, it is a record.
No problem there.  If a hyperlink is a control (which is what the 
great unwashed think it is), then clicking on it initiates a 
behavior and the author gets to specify what behavior that is.

If they want a very complex behavior, they get to write a 
script (which is what a processing spec is for the most part).
They might store that separately, they might inline that into 
a node.

If they simply want to target a frame, pass some parameters 
to it, they can do that too.  That is a script node as the 
world and most of the Web languages know it.  

All of this can be done without giving up anything except the
purity of data-declared markup.  That is already given 
up by the application languages we use, and in any FROM TO 
scheme in attributes.   I seriously doubt anyone will give 
us Java or JavaScripts in markup because we tell them that 
they are immoral.

> Now GOTO is a more abstract behavior that "Plop data into the
> pane named 'Joe'", but not _much_ more abstract. It certainly precludes my
> users from being offered a style option for display inline footnotes,
> footnotes in popup windows, or footnotes in a special area of the current
> display _without_ changing the markup of the document. This is progress in
> document representation, but not in linking.

I don't think so. For example, plunking a document into a pane is 
best spawned, not a goto which abandons state and leaps.  A get might 
be more the kind of thing that "plops".  As to the style options, 
there are other ways to think about that then the separate stylesheet 
although it is more flexible for sure.  For one, one can do 
as MID does an infer pane positions without specifying coordinates
as a frameset or FCS does.

MID made for three approaches, hard, tofu, and soft.
It separated the content layer from the MID layer.  
If a user wants to  display inline 
footnotes in a popup window without changing the markup, he 
puts the get in the MID structure.  MID is not about representing 
the data as much as enabling navigation and look and feel to 
be portable across viewers.  I said in the very beginning, 
here is an application language that takes a working 
approach to relationship linking.  It has an *optional* 
goto/gosub/spawn/other attribute if one needs state management.
 
> One major topic of this list for the last month has been addressing
> mechanisms. I know that the editors are paying attention, I expect that it
> will show in the draft in progress. If not, the rest of us will turn up the
> fires and bake the proposal more fully.

Yes.  We are having fun.
 
> >> I finally get it, I think. You don't belive that it's possible to implement
> >> the indirection from a link to the code to make behavior for the link.
> >
> >Nope.  I think is easier to implement a declaration on an attribute
> >that hints at behavior than to drag a DSSSL spec through the Internet.
> 
> DSSSL is one option. I'm on record as saying that we need to have CSS
> bindings as well -- since CSS is attracting people based on its
> functionality. But even if we just do DSSSL I want to be _able_ to use
> stylesheets. Putting rendering in documents will make that process hard to
> do, and will limit its scope to just those people who use _my_ software.

Ok.  We can agree to that.  I think the disconnect is the 
architecture.  MID is meant to be a browser-level layer.  It 
does some nice tricks.  For one, if one requires a sequence 
of displays which is rigid and precludes the ability to 
goto/next/previous a container, the chain element type is there to 
do that.  In procedural work with liability, this has 
to be enforceable.  So for an application with that 
requirement, it works.
 
> If I react strongly to this, it's because I remember just how far back
> Hypercard put a lot of really cool hypertext and teaching projects in the
> 80's by getting people excited by a fundamentally bad data model. Of a
> whole host of interesting innovative projects that I saw, only the Perseus
> project avoided the black hole of data engulfment that was hypercard --
> because they used Hypercard as a pure delivery vehicle and SGML and
> independent graphics archives to generate the stacks.

If I react strongly, it is because I watched the TEI community 
among others try to take IADS down because it did not meet their model 
although it was very successful at defending against the 
prevailing argument of the ODA community and others that 
SGML was only good for print applications.  We all have our 
crosses to bear.  I bear mine lightly because IADS is a raging 
success.
 
>    Now XML will be easier to munge than Hypercard stacks even if we take a
> shortsighted apporach to linking, and have to reinvent generic linking in
> 10 years (20 years after the establishment of generic markup as a realistic
> option). But I am not yet convinced that one extra table lookup in link
> definition is going to scare someone who is already using generic markup.

I don't either.  MID used locs.  I did not like where they ended up, 
but by that point, I couldn't change it.
 
> >> else you believe that in 10 years we will still have the same set of
> >> crippled user-interfaces that we have today, and that we won't want to
> >> change how our footnote links are interpreted without changing (pardon me)
> >> "every single ****ing document" we've ever created in the meantime.
> >
> >Nope.  I think a gosub is a gosub and a goto is a goto.  State space,
> >not user interface.  Read the MID documents sometime.  Altering the
> >documents to get rid of optional attributes is not exactly rocket
> >science.  Even SGML, nor will XML enable us to do what you claim
> >can be done.  We change them everytime we rehost.  With SGML,
> >we change them a heckuva lot less.
> 
> I've seen people retarget SGML instances without changing one jot or tittle
> of their markup (Perseus for instance). Now it's hard to do, because you
> have to get the markup right at the start. And people often oversell this
> aspect, because frequently a new delivery system offers new capabilities.
> And sure enough once you have new capabilities you often want to display
> information that wasn't marked because there was nopthing you could do with
> it before.

All true.
 
> >> Our miserable single browser windows, measly displays, and pathetic and
> >> disorienting frames are going to be history practically tomorrow. XML can
> >> do better than to require specific browser behaviours when defining link
> >> types.
> >
> >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.

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

I am saying that all of the types of behvavior 
you want so far in linking come down to gosub/goto/spawn.  In some 
examples, there are simply two gotos in the link.  I am saying that 
in some cases, it is better to let the application derive the 
format based on its own methods, but to enable the user to indicate 
on the linktype which primitive behavior is intended so state 
management is simpler.  The truth is, the MFC has more to so with 
how rendering takes place than a processing spec.  The Active-X 
control may have all of that built in just as they do now. In 
these cases, an XML linktype can be a more complex link 
with properties for that application.  No problem.

> I take you
> carps at my "academic" approach to indicate that I show signs of having
> thought through a consistent logical position.

If that satisfies you, fine.  I will take it that "pernicious" means 
I have a fine haircut and pass the compliment on to my barber.
 
> 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.

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 ++.
 
> >> It has to do better, if it is not to perpetuate in linking the mess that it
> >> hopes to save us form in document representation.
> >>
> >>    Linking behavior is a "formatting property".
> >
> >So you say.  But that is yet another religious assertion.
> 
> So is the "theory" of content markup. I had assumed that we were all
> co-religionists here (at least within a broad tradition, with a mixture of
> high and low church, conservative and reform).

I'll buy that.

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.
Working systems that provide useful functionality at reasonable 
cost to a range of skills are at least, a practical goal.  I 
do not believe after this many years of doing this work, that 
the complete separation of content and behavior are. 

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.

len

Received on Friday, 24 January 1997 14:30:55 UTC