Re: Relationship types

Len Bullard <cbullard@hiwaay.net> wrote:
> Joe English wrote:
> > To sum up:  no, "previous" is *not* equal to "goto", regardless of
> > whether Netscape and JavaScript implement it that way.
>
> We have also implemented a history list.  It is not a LIFO
> stack.  Click on it, and one "goes to" the target.  Previous
> and Next do not equate to a history list.  It is a goto, a
> gosub, or a spawn.  Simple state space management.  A nice
> thing to have because without it, you will not have interoperation
> except for where a specific processsing specification and
> specification language is used.  And you have to both have
> them and cart them around if you don't.


Hmmm...  Let me try again.

I do not disagree with the idea that the MID goto/gosub/spawn
model is useful and even necessary.  Quite the contrary:
goto+gosub+spawn+get is already two and a half features ahead of HTML,
which only supports "gosub" (or, for _very_ primitive browsers
lacking a LIFO history stack, "goto") and a limited form of
"get" (<IMG SRC="...">).

It's just that, although goto, gosub, spawn, and possibly get
may be necessary, they are not *sufficient* to support the kind
of applications I'd like to see buildable with XML.

I mentioned the MidasWWW history tree as an example of the
sort of things an application [*] could do if it had more
information about the link structure than is available in the HTML
(or MID [***]) model.  For another example, consider:

The documentation for a large Java class library might have
a node for each module, class, and interface, where a "node"
might be a distinct entity or a single element in a larger,
monolithic document:


    <!ELEMENT (CLASSDEF, MODULEDEF, INTERFACEDEF) - - %whatever;
	    -- ModInfo-style elements describing each
	       class, module, and interface, respectively -- >

A useful relation to add to such a document would be
(in post-TC HyTime notation, if I've got it right):

    <!ELEMENT CLASSLINK - - EMPTY
	    -- Links to relevant information about a class -- >
    <!ATTLIST CLASSLINK
	HyTime   	NAME	#FIXED	"HyLink"
	anchrole	CDATA	#FIXED
			"class  super  implements #LIST  module"

	-- Anchors: --
	class	IDREF #REQUIRED  -- Java class being described --
	super	IDREF #REQUIRED  -- Immediate base class  --
	implements
		IDREFS #REQUIRED -- Interfaces which this class implements --
	module	IDREF #REQUIRED  -- Module in which the class is defined --

	-- And for good measure, some reftype constraints: --
	reftype	CDATA	#FIXED
	    "class CLASSDEF
	     super CLASSDEF
	     implements INTERFACEDEF
	     module MODULEDEF"
    >



Now consider what an application [*] could do if it's handed
a big bag of MODULEDEF, CLASSDEF, INTERFACEDEF, and CLASSLINK
elements:

    + If a user lands on a MODULEDEF node, present a menu
      of all the classes defined in the module; on a CLASSDEF node,
      a link to the immediate superclass, a menu of all superclasses,
      a menu of all immediate subclasses, a menu of all interfaces
      which are implemented by the class, and a link to the module
      in which the class is defined; on an INTERFACEDEF node,
      all the classes which implement that interface.

    + Draw a class hierarchy diagram.

    + Answer queries like "what classes implement interface X?",
      "what classes are derived from class Y?", and "in which module
      is class Z defined?"

    + Build a table of contents of classes sorted by module,
      sorted by interface, or sorted by inheritance hierarchy.

    + Anything else a sufficiently clever application designer can
      think up.

    + Anything else a sufficiently clever end-user can think up,
      perhaps even on the fly.


That would make for a nifty tool, no?  But there is no way it could
be implemented if the DTD designer (or author) has to assign "goto",
"gosub", "spawn" or "get" behaviour to every anchor in the CLASSLINK.
Even if the behaviour is deferred to a stylesheet, some of these
things (like the class hierarchy diagram) cannot be even expressed
in terms of goto/gosub/spawn/get.

But again: I don't claim that goto/gosub/spawn/get is fundamentally
the wrong model.  There are plenty of hypermedia presentations which
resist organization into any structure more rigid than a general state
machine, and for these goto/gosub/spawn is *precisely the right model*.
My hypothetical Java library reference manual just happens not to be
one of those kinds of documents.

Here's why: it's true that the content provider can build a
wide variety of presentation structures out of one-way contextual
links (<A HREF=>) or the MID model.  But neither of those foundations
can support the last feature on my list: if an end-user wants to view
the manual with a presentation structure that the provider didn't
think of, he's out of luck.


> Y'all want DSSSL.  Fine.

No...  (Well, actually, yes, but that's beside the point).
I want an architectural foundation for hyperlinks that is
powerful and easy to use.  Easy to use means that authors
mustn't be required to learn Scheme or Java programming
in order to specify "click here, go there".  So the XML
link architecture needs to be more concrete than pure HyTime:
it needs a way to bind behaviours to links.  (While on
the subject, let me join in the chorus of support for
Jon Bosak's four requirements for how the binding
mechanism must work [**].)

Easy to use also means that, ideally, authors shouldn't
have to do a whole lot more than filling in a bunch of <CLASSLINK>
elements in order to enable the sorts of applications
outlined above.   That means, I think, that XML also needs something
more than the MID model as a core set of specifiable behaviours.
(What that "something more" might be, I don't know, though
I've a few ideas.)


--Joe English

  jenglish@crl.com

[*]   Here I use "application" in the conventional rather than the SGML
      sense of the word.

[**]  <199701232234.OAA19977@boethius.eng.sun.com>

[***] My understanding of "the MID model" is based on the
      November 1994 draft spec; I've not yet read up on
      the current version, but it appears to have some
      new functionality, including a multi-anchor, general-purpose
      "relationship" link that would probably work as
      an architecural base for "CLASSLINK".

Received on Friday, 24 January 1997 16:09:37 UTC