🚀 go-pugleaf

FrameMakerLinks_  (<< another subject on using 'tags' for linking products)

		-----------------------------
		UTILIZATION OF FRAMEMAKER 
	   	FOR DYNAMIC LINK CAPABILITIES

			Scott Arthur Moody
			Boeing Commercial Airplane Group
			July 31, 1992

INTRO:

   My work over the past few years has delt with building and utilizing
tools that work in a distributed environment. I have been using Framemaker
as a prototyping tool to show the benefits of a hypertext rich environment. 
Frame has been connected to other life-cycle products in an RPC (remote procedure call)
environment. Although showing the results of navigating through a full hypertext
system is impressive, I feel we must address the generation aspects of
the vast amounts of links. Manual link creation is analogous to assembly
language programming which some of like to avoid.

   I would like to know if others are looking at these same issues
and am especially interested to know the type of applications
that all this linked information is being applied to. Examples
include: 
   Software Reuse, 
   Database Browsing, 
   Interface Descriptions for Code Generation,
   and navigation between all the different life-cycle work products
   including Frame documents.

---------------------------------------------------------------------------
ISSUES:
   (a) Maintaining Links in automatically generated Frame Files
   (b) Creating Links in a 'point-and-click' manner, outside
       of Frame's manual 'hypertext marker' mode.
   (c) Creating links to non Framemaker information.
   (d) Automatic generation of 'link definitions'
   (e) Awareness of 'link definitions' in a distributed environment.
	- manual
	- automatic
   (f) Changing where a 'link definition' is physically located.
	- How do existing links get to the new location?
	   - placeholder, broadcast, etc.
   (g) Allowing users of links to be involved in modifications
       to what they are pointing to.

   (h) How should this type of information influence future SGML
       standards?

TERMINOLOGY:
   node		  : holder of the object (what you point/link to)
   link		  : act of connecting to a node of information
   link definition: the 'newlink' definition, essentially a 'return address'
   rpc		  : remote procedure call  
   message passing: sending information via an 'rpc'
   document generation: actually creating/generating the document from a higher
			level description, and usually a domain specific 
			translator.


LINK_DEFINITIONS:
------------------
  My work is mostly concerned in automatically generating frame documents
and embedding a necessary set of hidden hypertext markers. These can be a collection
of 'outward' links or a number of 'link definitions' describing places that
others can navigate to. 

  The question then becomes how do others in a distributed system
become aware of these link definitions? And how would one make a link?

  In our system all frame documents are 'read-only' and locked so
there are only 3 ways to know about interesting features:

	1) manually looking at document - then maybe unlocking and looking
	   at embedded 'markers'
	2) selecting hypertext 'outward' objects which send an rpc-message 
	   to an external controller. The message content will
	   conform to a known grammar, but contain at least
		  (a) the name of the 'link definition' that
		      others can use to get back to you.
		      (i.e. Return Address)
		  (b) other information such as what the link
		      is about, allowing others to know the effectiveness
		      of making that link. 
		      (i.e. description, abstract, keywords)
	3) providing 'ALERTS' that have some of the description information
	   and attributes that help users determine.

  KEY ISSUES:
   (a) there is no logic built into frame documents only 
       item names, descriptions, and possibly return addresses. 

   (b) The information is read-only, the links created are NOT embedded
       in the Frame documents. Instead, another tool or set of tools is keeping
       these links. This other tool is called the Link_Capture.


OTHER_LINKABLE_PRODUCTS:
------------------------ 
  Since the 'return' address provided in the link_definition phase
is basically a 'message' that is passed back to Frame, links to 
other work products are also provided. The 'return' address must
describe the mechanism to implement the link navigation phase. This
might include the (node,rpc#,proc#,message), or a higher
known abstraction that ultimately results in this information.

LINK_CAPTURE:
---------------
  The controller is a rpc-server we call 'Link_Capture'.
It keeps a database of 'links' that have been made, and provides
a limited set of (visible) operations on those links including:

	1) Create Link
		(a) select one side of link
		(b) select other side
		(c) capture description about why link is being made
	 1.1) Many-to-One Links can be created

	2) Follow Link
		(a) can follow link in either direction
		(b) Implemented by sending an RPC message to
		    FrameMaker (on the correct machine) 
		    with a message to traverse to the link definition
		    that was captured during 'Create Link' phase.

	3) Conditionally Follow Link
		(a) allows external selection of follow MODE.
		    This 'state' is kept until changed.
		(b) then accepts 'Dynamic Follow Link' message
		    that goes in the direction of the MODE

	4) Dump the links
		(a) Save to a file
		(b) Return the links via an RPC message
		    (Used in Code Generation Phase described below)
	5) Restore Links
		(a) From a file
		(b) From a RPC message
		    (So scripts that capture the links can be
		     run to re-establish those links).

	7) Delete Links

OTHER LOGIC TOOLS:
------------------
   The beauty of providing a visible/published link capability is that other
tools can provide additional logic for following those links. This
section describes a language for describing that logic.

   We have developed a Distributed Communication Language, called Denali,
that provides an Ada like syntax to describe and facilitate operations between
distributed objects, essentially distributed 'glue'. Denali provides
an X-Window interface that is easily described and
manipulated by the language. Denali also supports class and instance
object definitions with the added benefit of 'persistent' instances
stored in the Empress Database.

   Individual Denali objects can receive and transmit RPC messages. Central
to effective use in a Framemaker link environment is the concept of 'Threads'.
The calling tool continues running after passing the necessary
information while the receiving tool also continues to run. This is very
important because the 'follow link' message can be initiated from a
Frame document, and the 'link_capture' tool might then send a message
BACK to Frame to follow that link. If Frame were locked in an RPC message
we would have a deadlock situation.

   To implement threads, Denali has extended the normal RPC protocol 
to support the rendezvous concept so execution can occur after the 
message transmission. The semantics are not as rich as some 'thread'
packages that do not have to perform a rendezvous, but they are as
powerful as the Ada rendezvous semantics.

   The Denali Server accepts a set of 'class' level messages for
query, display and creation of instances. This allows information objects
to be invoked (displayed in a X-Window) from external messages. Thus
a 'link' might invoke a Denali window instead of a Frame window.

   The 'Link_Capture' tool described above is implemented as a Denali object
which can be running on any number of distributed nodes at the same time.


USERS OF THIS LINK INFORMATION:
-------------------------------

   Is there any way to capitalize on all the links being created
   outside of the usefulness on manual hypertext navigation?

CODE GENERATION:

   Our work is looking at the linkage between the different work
products in a software development life-cycle. Of particular interest
is in how to describe the interfaces between services (procedures/LRU's)
and users of those services. Ada code can be generated with varying
degrees of 'binding' completed allowing final decisions to be made
without effecting already 'bound' functionality.

SOFTWARE REUSE:

   Searching and navigation through the various users of software components
can be achieved if their use is linked - and not just 'cut-and-pasted'. 

OTHER GENERATIVE VIEWS OF YOUR WORK PRODUCTS:

   Generation of documents that conform to the 'view' you wish. In the
Frame environment, a MIF document is generated with embedded hypertext
links that conform to your view.

GROUP COOPERATIVE WORK 

   We are exploring how names and functionality
can be delayed even when others are already using proposed information. The
'chicken-and-egg' problem where everything isn't known up-front and everything isn't
totally top-down. The links are created between the supplier and users of
information. 
   
   This seems to be the crux of group cooperative work and is usually 
managed in a manual (non computer) and in-person manner. We are exploring how links
to empty (tbd) items can be made for a future binding process. That future
binding may still be manual (point-and-click), but concepts such as sending
electronic mail back to the originator of the unknown link. Currently people
need to manually find out who made the original link.

MAIL SERVERS FOR EXTERNAL SERVICES:

   The distributed tools we have been using rely on high performance 
workstations. How can these concepts be migrated or utilized by
lower level computers? The concept of a 'mail server' is being explored. Here 
specific services are published and then invoked from other computers from
a simple electronic mail message.

   Our main use of the mail facility is when links are broken or modified. Mail
can be sent to the current users of those links to let them be involved
in any group decisions. Creation of the links requires specifying the
necessary information to notify the person involved. Issues that remain
include: unread mail that needs timely response
(they were on vacation, or don't work there anymore), and other roadblocks.

CONCLUSION
----------

  Framemaker is an excellent vehicle for showing the concepts of a distributed
linked environment. Coupled with other tools, especially a 'link database'
outside of Frame, allows a platform and tool independent use of those links.

  Unfortunately Frame would also need some modifications to make maximum
benefit of a group cooperative environment. The changes could include

  * by-directional links (both x-ref and hypertext)
  * executing commands when changing hypertext information (to let
    others know about the change)
  * embedding links in frame via rpc calls


REFERENCES
-------------

   'Using Hypertext in Selecting Reusable Software Components'
	- Michael Creech, Dennis Freeze, Martin Gris
	May 1991, HP Laboratories Technical Report: HLP-91-59

   'Hypertext and CASE'
	- James Bigelow
	March 1988, IEEE Software

   Information Capturing and Browsing Capabilities - Requirements
   for the Intelligent Reusable Library Framework (IRLF)
	- Scott Arthur Moody
	August 1991
	Boeing Technical Report: D180-32854-1

   Interoperability Within the Life-Cycle Information Backplane (LIB)
	- Scott Arthur Moody
	August 1991
	Boeing Technical Report: D180-32853-1

   Exploring Frameworks and Representations for
   Domain Specific Automatic Code Generation
	- Scott Arthur Moody
	Nov 1991
	4th Annual Software Reuse Workshop


-- 
Scott Moody   (206) 477-4295   "There are no answers .. just cross references"
     scott@shuksan.boeing.com  
     uunet!bcstec!shuksan!scott