Re: Relationship Taxonomy Questions

At 9:40 PM 1/23/97, len bullard wrote:
>David G. Durand wrote:
>>
>> At 3:19 PM 1/23/97, Len Bullard wrote:
>> >My point is simple:  no normative linktypes.  A way to express a
>> >linktype is already available.  It is an element type.  Will these
>> >interoperate?  Only if the application programmer understands
>> >the behavior implied or noted.  But those are application conventions
>> >and do not belong in the normative parts of the XML specification.
>>
>> This is rather oversimplified.
>
>No.  Read Eliot's earlier posts on the subject.

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

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


>> The addressing mechanisms we are defining
>> would be unliekly to work well without explicit support in the form of
>> syntactic and semantic definitions of how they should be coded and what
>> they should designate.
>
>The addressing mechanisms who are defining?

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.

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

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.

   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.

>> 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."
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 take you
carps at my "academic" approach to indicate that I show signs of having
thought through a consistent logical position.

And personally I think the example of EBT's document display software is a
lot more relevant than VRML's budget simulation software.

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

   -- 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 Friday, 24 January 1997 12:57:57 UTC