From: DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro")
Newsgroups: comp.text.sgml
Subject: Links and Such
Date: 14 Apr 92 11:55:58 GMT

I re-read the information in *The SGML Handbook* on links and I
am now a believer.  Links are not that complicated and clearly
provide some serious power.  Here are my initial thoughts.
(If I have obviously misunderstood something or missed something
important, please bring it up here.):

1. Any SGML-based editor that does not support all three flavors
   of links is seriously flawed.  With link support, any SGML editor
   should be able to preserve the formatting information it lets
   you associate with a class of element or instance of an element
   in a standard way (e.g., link declarations).  For example, SoftQuad's
   Author/Editor lets you attach formatting parameters to any element
   type.  It should (but doesn't) implement that association via SGML
   implicit links.  Also, any editor that supports explicit links (mapping
   elements in my DTD to elements in a target DTD) would instantly
   enable the sort of tag-to-tag mapping that I've been going on about
   being able to easily write programs to do.  This was, of course,
   Erik's point in the Limerick discussion.  I should, in other words,
   be able to import a LimerickDoc document and export a PoetryDoc
   document from my editor just by choosing the appropriate explicit
   link declaration.

2. Links suffer from a problem that is a general problem with SGML,
   the separation of specifications and instances that use those
   specifications.  I think this problem is at its worst with links.
   With links, the link attribute
   definitions for an element (especially an element instance in the
   case of ID links) are too separated from the element itself.  This
   isn't a problem when you've got an SGML editor, but when you are
   tagging by hand, it is prohibitive.  This is a problem only in the
   sense that it makes authoring difficult--the design itself is not
   flawed.

   One thing I think I would like to see is the ability to refer, not
   from a link declaration to a specific element (ID link), but from
   a specific element to a link.  As I understand it, I can either
   define a link that applies to *all* instances of a given element,
   or a link that applies to a *single* instance of a given element.
   What I want is a link that applies to *multiple specific* instances
   of an element.  This is analogous to the DEF system in BookMaster.

   In BookMaster, I have DEF tags that let me define named sets of
   attribute values for a given element class.  For example, for
   figures, I can do something like this:

   <figdef id=bigfig width=page frame=box scale='1.2'>
   <figdef id=smallfig width=column frame=rules scale='0.7'>

   From any FIGURE element, I can refer to a specific DEF:

   <figure defid=bigfig><!-- picks up presentation values from
                             FIGDEF called 'bigfig' -->
   </figure>

   The advantage of this approach is two-fold.  First, I can have a
   one-to-many relationship between DEF elements and presentation
   elements, and because the association is defined on the presentation
   element, the author knows what's happening.  The problem with ID
   link is that there's nothing at the element being linked to that
   indicates there's a link to it--the author would have to look at
   the link process definitions to see that.  The DEF model solves
   that problem by reversing the direction of association (backward
   instead of forward).  Given this backward association between
   element instances and links, I could recast BookMaster's DEF
   function as link processes without any loss of function or utility.

3. The ability to set parameter entities within a link declaration
   makes marked sections more powerful than they are now because you
   have a chance to apply application-controlled dynamics to the
   parameter entities that control marked sections.  For example, in
   our current BookMaster-like SGML application, we use marked sections
   for what BookMaster calls "process-specific controls", for example
   ('

   <!
   This is used when the output processor is of type "display"
   YY>
   <!
   This is used the the output processor is not of type "display"
   YY>

   To set a processor, we currently have different "setup" files
   that pull in different external entities with different settings
   for the disp and xdisp parameter entities.  The author must select
   which setup file to use, where a setup file corresponds to a particular
   process.

   I can now use (or could if my parser supported links) links and
   some application function to define the values of the disp and xdisp
   parameter entities, simplifying things for the author tremendously.

4. Links will not solve all outstanding problems, but coupled with
   HyTime constructs, might be able to do quite a few very interesting
   things (SGML links coupled with HyTime conloc hyperlinks could be
   a very powerful combination).  I don't know enough about the problems
   of composing documents or about DSSSL to know if the contention that
   SGML links can't do everything you need to for specifying formatting
   is true, but I would be surprised if that were true.  However, it
   might be possible to come up with more direct specifications than
   SGML links (or not, I don't know).  However, I would be hesitant
   to write off SGML links without a lot of investigation first.

The main drawback I see to links is their separation from
the document elements that use them.  This is a problem that is easily
solved by existing editor technology, but it becomes a conceptual
or perceived barrier, especially for people used to languages like
TeX or systems like InterLeaf where everything is together and
very direct.

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-543-7091
IBM Corporation
Research Triangle Park, NC 27709
Newsgroups: comp.text.sgml