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