🚀 go-pugleaf

Within IBM we are working on defining an SGML language to
replace the current DCF-based BookMaster language.  This language
design is being done without regard to any product or implementation.
It is merely a design.  In the course of discussing the design,
which is highly focused on hyperlinking and HyTime, I posted the
following to our internal design forum.  I thought others might
find it interesting because it demonstrates a use for what I think
is a very powerful but little understood aspect of HyTime, the
PATHLOC, and puts it into a concrete context with interesting implications,
if I'm not totally off my nut.

The context of the following post is a dicussion of the representation
and use of paths, threads, and webs in the context of SGML-based
hypertext.  We define paths to be constrained to the logical
hierarchy of the document, threads to be unconstrained but
unbranching, and webs to be unconstrained and branching.
We were also discussing the problem of circular paths.

In our design, our basic model for accessing an SGML document
is via retrieval against the SGML elements, as opposed to
sequential processing driven by parsing.  The DynaText product
is a good example of this access view.

Here now, the original post:

>A more difficult problem would be how can I produce hardcopy of
>selected paths through such a document.  A given path could correspond
>to, say, detailed maintenance on some module in a device.  The parts
>in a hyperdoc may be scattered around the document -- giving the
>hypertext user no problem.

In a system based on retrieval, getting the hardcopy view of
the path would be easy, assuming you have the node list that
defines the path.

In our design, we could build in the ability for elements to
define what path they are in into the language
explicitly with something like a PATH= attribute that takes the
name of all the paths within which a given element participates:

<div path="task1 task4 task10">

I then define a query that names the path:

<pathlist pathname=task4><!-- query is "retrieve all elements
                              with a PATH= value of "task4" -->

Just to confuse everybody, I could also use a history function
in an online system to capture paths and express them as
SGML documents that could be rolled back into the original
document or separately interchanged with others.

Another thing to think about is representing a set of related
threads as a tree.  If the threads are represented as a tree,
any thread can be accessed via a HyTime PATHLOC element.
This is really fairly simple.

Say I use a history function to capture a bunch of threads as I wend
my way through the docuverse.  I can make these threads into a tree by
treating each thread as an ordered list of nodes, where each node
contains a pointer to some content element (note that multiple nodes
in a thread could point to the same element).  To make the tree, find
the areas of congruence, starting at some common node, then find
divergence points (assuming a common starting place for each thread).
I now have a tree representing my paths (if it helps, imagine that the
tree below is itself an SGML document):

                   root
                   /   \
                  A     B
                 / \   / \
                C   D E   F

A pathloc expresses a tree as a matrix by making each path through
the tree a column in the matrix, like so:

         Paths

        1 2 3 4

        R R R R
 Nodes  A A B B
        C D E F

I can now locate all the paths using a two-dimensional reference.
The paths are numbered left to right, so
path 1 is R,A,C, path 2 is R,A,D, etc.  Now I have an unambiguous
way to refer to paths, which means I can now link to paths
using HyTime location mechanisms.  Given the path table above,
I can link to any path like so:

<pathloc><!-- Finds path 1 in a given pathloc matrix -->
  <dimspec>1 1
  <dimspec>1 -1</>
</pathloc>

The first dimension locates in the horizontal direction, and
says start at column one and go 1 column to the right (e.g.,
locate the first column).

The second dimension locates in the vertical direction and
means start at row 1 and go to the end of the row (or go
minus one from the end of the row).  In HyTime, (1 -1) always means
"select the entire range".

Note some other properties of the path table.  It shows
me for any node what paths it is in.  That is a very
important query in many instances because you want to
know who will be likely to see something, say a safety
notice.  And of course I can get the size of a path,
easily define subpaths and re-derive the original tree simply
by normalizing each row of the matrix to remove duplicate nodes.

Remember too that the path is a one-level abstraction
of our document.  The nodes aren't the content of the document,
but a pointer to the content.  Knowing this, I can easily
find circular paths by querying the pointer value of each
node in a given path and comparing them.  I think, but I'm
not sure because I'm not a mathematician, that you could apply
set or combinatorial calculus or some such to the query
results to find such cases.  I can certainly define a HyQ
query that given a path will return the list of nodes with
duplicate content pointer values (e.g., IDREF= values).

If you've followed along this far, you might be starting to
realize that the real power of HyTime is not it's ability
to link things, but the analytical and expressive power that
derives from its language for expressing locations, a language
that we have never had before.  I think that this means you
could actually develop a formal mathematics of document
analysis and navigation using the primitives HyTime defines.

Dr. "Eliot Kimber" Macro