Re: Relationship Taxonomy Questions

With the understanding that some aspects of relationship linking are
declared out of scope for this discussion, the following is submitted 
as an example of prior work on the concepts of relationship forms 
based on the HyTime ilinks of that period.  This is from the 
extant MID documentation at http://navycals.dt.nav.mil/mid

This source has the virtue that it is implemented and works 
based on the HyTime of that time.  So where one wants both 
relationship maintenance and behavioral interoperability, it 
serves as an example of a viable approach.

A requirement of that project was that both relationships and 
abstract look and feel behaviors needed to be portable.  
Since for that project, behaviors were either interface behaviors,
therefore easy to specify based on current windowing systems practices,
and application behaviors 
with regards to traversal based on scripts, it was straightforward 
to create both architectural forms and element types to meet the  
requirement using HyTime constucts.  Note that behavioral 
specifications even where relationship linking is used depend 
a great deal on how state variables are treated.  Say, duh.

********** From MID Application Guide *************

Transitions can be specified by an author to occur between
infoContainers, or within an
infoContainer to render new panes or controls. Types of transitions may
include goto,
gosub, or spawn. The difference between these transition types lies in
the way the
application handles the state of the currently-rendered containers.  For
example, a button on a pane within the infoContainer might contain a
script that implements a 
goto transition to infoContainer "IC-1." In this case, all non-global
variables (e.g., those set by the infoContainer, or by a pane in the
infoContainer)would be cleared, 
and the state space would be set to represent the variables of the
target 
infoContainer.

In a similar case where a gosub was specified in place of the goto, the
source
InfoContainer variables would be maintained, and then restored at the
completion
of rendering of the target "IC-2." Using a spawn would instruct the
application to
simultaneously maintain both sets of state variables. 

By these mechanisms, an author has the ability to control the appearance
of an
application, without undue restriction on the application's unique look
and feel. 

A get element specifies that information at a source be retrieved, and
rendered at the
point of the get. This element represents one of the most significant
abilities of the MID design. The get allows source documents, delivered
and maintained independently, to
be bound to the presentation at run-time. It also allows source
documents to be in
various formats, and still be accessible to a MID instance. The power of
HyTime
location and linking facilities is what makes this capability both
practical and standard. 

The relationship element is a construct, based on a HyTime ilink, that
allows authors
to establish connections between various types of information in a
document.
Relationship can be used to implement hotspots in text and graphics. The
relationships in a MID document are located in the pool. Because the
relationship
element is based on a HyTime architectural form (i.e., ilink), multiple
elements can be
relationships without being called "relationship." Each of the elements
derived from the
MID relationship element will define a specific type of relationship,
with the instances
of that element linking information that is related in the defined way.
Rendering of the
relationships is up to the application; often the anchors of the
relationship links will be treated as hotspots that can be selected by
users, and traversed according to the rules of HyTime ilinks. 

Relationships are based on named connections between related
information. This
enables the author to specify the reason for a particular link, in
addition to specifying which objects are linked. Thus, the nature of the
relationship is 
transported from source to end-user. 

Gosub indicates that the state of the current infoContainer be saved
and the target object rendered.  Gosub targets may be of the following
types: infoContainer, chain, pane, conditionalPane, alert, mid.  Gosub
is forbidden to an infoContainer that is nested in another chain.
Gosub is forbidden to a pane or conditionalPane that is nested in
another infoContainer's client area or paneGroup.

Goto indicates that the current infoContainer be abandoned immediately
and the new infoContainer launched.  Goto targets may be of the
following types: chain, infoContainer, mid.  Goto is forbidden to an
infoContainer nested in another chain.  Return values from objects
which are targets of goto are lost, because there is nothing waiting
on the returned value.  A goto which targets this MID document is
equivalent to a restart of this MID document.

Spawn indicates that control flow splits.  Spawned targets may be of
the following types: infoContainer, chain, pane, conditionalPane,
mid.  Both parent and child compete for focus in the
application display space.  Spawn is forbidden to an infoContainer
nested in another chain.  Spawn is forbidden to a pane nested in a
client area.  Return values from spawned objects are lost, because
there is nothing waiting on the returned value.  When a spawn is
encountered, control stops in the calling script, the target is flowed
until it reaches an idle state, then the caller continues until it
reaches an idle state. 

<!ELEMENT ( gosub | goto | spawn) - O ( %locs;)*>
<!ATTLIST ( gosub | goto | spawn) 
  HyTime NAME ilink
  HyNames CDATA "linkends target"
  anchrole CDATA "me target"
  target IDREF #REQUIRED
>

get
  Get expresses that the information at the source be collected,
concatenated, and rendered at the point of the get.  

If space is specified, the members of a target aggregate will be
delimited by a single space before the data is concatenated.  If
normalize is specified, leading and trailing white space is removed,
and multiple contiguous spaces are converted into a single space.  -->

<!ELEMENT get - O ( %locs;)*>
<!ATTLIST get
  HyTime NAME ilink
  anchrole CDATA "me source #AGG"
  HyNames CDATA "linkends source"
  source IDREF #REQUIRED
  space ( space | noSpace) space
  normalize ( normalize | noNormalize) noNormalize
>
A ‘get’ element may point at (i.e., have as its content source) another
get element, 
and so on in a chain of indirection to the final data

relationship
  The relationship form conforms to the architecture for a HyTime
ilink.  It expresses an authored relationship between two identified
objects.  The application must provide its own element and attribute
declarations for hyperlinking according to the HyTime standard.  This
pseudo-declaration is provided as a model for the HyTime ilink.  The
generic identifier of the relationship governs the relationship
semantic.

The traversal semantic of the relationship is governed by the
traversal attribute.  If traversal is set to be undefined, traversal
decisions will be left up to the application.

Attributes may be added to change traversal from hotspot marking
(interrupt) to hotspot information by request only (polling).  This
would prevent hotspot clutter in an on-line index, for example.

<!element relationship - O ( title, (%locs;)*)>
<!attlist relationship
  HyTime NAME ilink
  MID NAME #FIXED relationship
  relationshipName #CDATA #FIXED
  id ID #IMPLIED
  anchrole CDATA #FIXED "antecedent #AGG consequent #AGG"
  linkends IDREFS #REQUIRED
  privTrav NAMES #IMPLIED
  extra NAMES #IMPLIED
  intra NAMES #IMPLIED
  endterms IDREFS #IMPLIED
  aggtrav NAMES agg
  traversal ( gosub | spawn | goto | undefined) spawn
>

Application of relationship applies to hotspots in text and graphics. 
In the case of graphics, the identification of an object to link to is
via a notation 
(i.e., names of objects/zones must be available through a notloc).

A relationship of traversal type ‘gosub’ to a script will be treated
like a function call, except that the script is lexically contained only
within the MID instance, not within the other end of the relationship,
and not at its own location within the SGML instance (because its
container might not have been flowed). Note that relationship is an
architectural form.

Received on Wednesday, 22 January 1997 17:23:36 UTC