XML-LINK

[W. Eliot Kimber]

At 06:46 PM 6/1/97 -0500, len bullard wrote:
>> 1. The "I know everything mode", in which you need both to know the
>> boundaries of the documents you need to know about (i.e., a "bounded object
>> set") and a general processor capable of doing the processing and holding
>> the result for some reasonable length of time. This is the
>> HyBrowse/Hyper-G/Intranet approach, in which the bounds of the system are
>> fairly well defined and you have the infrastructure you need to manage all
>> the link information more or less persistenty.
>
>Isn't this also the mode of WinHelp?  WinHelp uses a restricted target 
>set (footnotes in page delimited chunks), but the rest of the
>hyperlinking 
>is topical based on the project file (defines the objects whose topics 
>are targets) and the #define files (string and paired ID) for the 
>software to use for contextual help, and the compiled files.

Relating parts of a program to entries in help files is really nothing more
than providing a query interface to your browser that lets you find things
(the entries) by property (the program object name or menu hierarchy or
whatever).  Not really hyperlinking in that sense, just plain old access.

You could, however, represent the relationship between the program objects
and the code objects by creating a hyperlink that used queries that were
interdependent, e.g.:

<help-to-code-link xml-link='extended'>
 <locator id=entries role="help-entry">
 select(entries_with_IDs(help_file($help.filename)))
 <!-- Returns list of help entries in file named by variable
      "$help.filename" -->
 </locator>
 <locator role="code-object">
 for_each(locaddr(has_id("entries")),
   select(code_objects($code.set), code_object_with_id(current_node()))
 <!-- Returns list of code objects whose names match the name
      of help entries returned by the "help-entry" role's
      locator. -->
 </locator>
 <!-- NOTE: in HyTime, you would also indicate that these two anchors
      are "correspondent anchors", meaning that for each member of one,
      there must be exactly one member in the other and that the two
      lists correspond in the order they are addressed.  Here, the
      use of the first anchor's list in generating the second ensures
      that these constraints hold.
  -->
</help-to-code-link>

Because the "code-object" role's query depends on the "help-entry"
role's query (the second iterates over the first), this single link defines
the assocation between all code objects and all help entries for a single
help/program pairing.  You could also create one such link for each pair,
but we really just need to express the intent, as the implementation will
probably be hard coded.

Note that this is very similar to using a DynaText style sheet to associate
hyperlinking style with element types, except that here the relationship is
defined more abstractly and distinct from any particular implementation of
it (apart from interpretation of the query notation itself, which in this
case, I've made up for this example).  For example, given the link above, I
could use it as a specification to guide me in creating the equivalent
DynaText style functions and SDK extensions to make DynaText into a help
system.  The link above defines the relationship semantics, the programmer
of the DynaText customization implements it.

>> 2. The "I only know about what I have seen or am now seeing" mode.  This is
>> the normal "Web" mode or the Panorama mode (except that Panorama only
>> remembers what it knows about the current document, unfortunately).
>
>How does Panorama store linking information?

For documents read in, it just keeps it in memory.  For Webs you create
with it, it creates HyTime documents with the necessary location addresses.
 Apart from Webs, it never keeps linking information around from documents
opened prior to opening the current document in the same Panorama session.
Panorama does provide bi-directional traversal for contextual (in-line)
links, but only within a single document--having used a contextual link to
traverse from one document to another, it doesn't remember the links that
started in the first document in order to provide the back links to any
clinks in the first that point to the second.  It does, of course, provide
a "go-back" feature, but that's different, as going back is not traversal
(as both XML Link and HyTime are careful to point out).

>> Note that the two modes can be combined, such that you might know
>> everything about one set of documents but only about pointers to another
>> set.  The data structures needed to manage knowledge of the links is the
>> same in both modes, the only question is when do you gather the knowledge?
>
>Well, not just when, but how is it packed if it is in separate files for 
>different processors?  

Who cares?  We're talking about implementation, not data representation.
If you want to interchange the result of building these data structures,
use the HyTime property set, build HyTime semantic groves, and interchange
those, either as objects using some object interchange standard (e.g.,
CORBA) or spit out the equivalent canonical grove documents.  Or define a
standard relational schema.  Or define a document type that expresses that
tables.

We should expect some standardization of the APIs for communicating about
hyperlinks and their properties, but not standards for the representation
of the internal data structures programs really use (I wouldn't expect most
implementors to use the HyTime property set as their object model
directly--there's too much room for optimization, especially with respect
to tool-specific features). 

Cheers,

E.

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)