Hyperlink in HyTime


Subject:   Hyperlink in HyTime 
Author:    W. Eliot Kimber
Email:     eliot@isogen.com
Date:      1998/10/15
Groups:    comp.text.sgml

Yang jung shik wrote:

> I have very confused about the definition of ilink, varlink, agglink. I need
> some example for these links.  Especially I have big trouble in
> understanding the role of "anchrole" these links.
> If any one have any answer or have some examples, please let me know.
> Thanks in advance.

The HyTime architecture defines a hyperlink in general as being a typed
relationship between two or more "anchors" (an anchor is a list of one
or more objects, such as SGML elements).  Thus, at a minimum, a
hyperlink consists of two anchors, establishing a relationship between
the members of one anchor and the members of the other anchor.

Because a hyperlink represents a relationship, each anchor is said to
play a unique role in the relationship. The role of each anchor is
designed by a name, thus "anchor role".  For example, a hyperlink that
establishes the relation ship "defined as" between mentions of things
and their definitions might be defined in abstract as:

- Relationship type: "defined as"
  - Role 1: "mention" (of thing)
  - Role 2: "definition" 

This could be represented schematically as:

  mention <--- defined as ---> definition

Using SGML, there are essentially three ways you can represent this
abstract model syntactically.  The HyTime architecture provides all
three, represented by the architectural forms "hylink" (hypertext link),
"varlink" (variable link), and "ilink" (independent link).  All three
forms describe the same abstract model but provide different syntax
choices for creating hyperlinks in SGML or XML documents.  The
differences in the three forms is how the anchors are addressed.  To
create a hyperlink you must address the members of each anchor in some
way. The different hyperlink forms do this in different ways.

The hylink form uses one attribute for each anchor role. For example, to
create a "defined as" link using the hyperlink architectural form, you
would do this:

<defined-as 
  mention="some-element-id"
  definition="some-other-element-id"
  anchrole="mention definition"
  HyTime="hylink"
>

Where the attributes "mention" and "definition" are declared as IDREF
(or IDREFS).  These attributes are called the "anchor addressing
attributes" because their purpose is to address the anchors of the
hyperlink.

This hyperlink asserts that the element "some-element-id" is a mention
of the thing defined by the element "some-other-element-id", e.g.:

<deflist>
 <dlentry id="some-other-element-id">A red or green fruit</dlentry>
</deflist>
 ...
<p>An <defined-term id="some-element-id">apple</defined-term> is often
used as a symbol for teachers.</p>

The hylink form is in general the easiest to use as it's syntax is the
most direct and easy to understand, as well as the most compact.  You
can use any form of address your processing supports with the anchor
addressing attributes, not just ID references. For example, if you
wanted to use URLs or Xpointers, HyTime doesn't care (as long as you
provide the appropriate declarations so that a HyTime-aware processor
knows what your intent is).

The "varlink" (variable link) form uses subelements to address the
anchors, rather than attributes. However, the meaning of the link will
be the same. To create instances of the defined-as link, you could do
something like this:

<varlink linktype="defined-as">
<anchspec anchrole="mention">some-element-id</anchspec>
<anchspec anchrole="definition">some-other-element-id</anchspec>
</varlink>

or

<defined-as HyTime="varlink">
<mention HyTime="anchspec">some-element-id</mention>
<definition HyTime="anchspec">some-other-element-id</definition>
</defined-as>

The "anchspec" (anchor specification) element form contains the
address(es) of the members of that anchor. Each anchspec uses the
"anchrole" attribute to say what anchor role it is addressing the
members of.

The second example takes advantage of the defaulting mechanism for
varlink where the element type name of a varlink-form element is taken
as the link type and the element type name of each anchspec-form element
is taken as the anchor role name. 

Again, the content of each anchspec-form element can be any form of
address your processing system supports. You can also use normal
architectural renaming to move the content of the anchspec element to an
attribute. For example, to use the style of markup used by the XLink
"locator" form, you could do this:

<varlink linktype="defined-as">
<anchspec 
  anchrole="mention" 
  href="#id(some-element-id)"
  HyNames="#ARCCONT href"
  loctype="href QUERYLOC Xpointer"
/>
<anchspec 
  anchrole="definition"
  href="#id(some-other-element-id)"
  HyNames="#ARCCONT href"
  loctype="href QUERYLOC Xpointer"
/>
</varlink>

The "HyNames" attribute says that the "architectural content" (#ARCCONT)
will be found in the value of the attribute named "href", rather than in
the content of the anchspec element, where it would normally be found.

The "loctype" attribute is a HyTime-defined attribute that defines what
form of address a given attribute (or element content) uses. In this
case the attribute named "href" is an Xpointer. In this case, the
loctype attribute says that the attribute named "href" is a queryloc
(query location address). A query location address is governed by some
declared notation, in this case, a notation called "Xpointer".  Thus a
HyTime-aware processor will know to pass the value of the href attribute
to whatever bit of software resolves Xpointers.

As the HyNames and loctype attributes in this example will always have
the same values, they could be declared as fixed attributes (this
example includes all the declarations needed to form a 100% complete
HyTime document, including the architecture use declaration):

<?xml version="1.0"?>
<?IS10744 arch
  name="hytime"
  arc-public-id="ISO/IEC 10744:1997//NOTATION Hypermedia/Time-based
Structuring Language (HyTime)//EN"
  dtd-public-id="ISO/IEC 10744:1997//DTD AFDR Meta-DTD
Hypermedia/Time-based Structuring Language (HyTime)//EN"
  form-att="HyTime"
  renamer-att="HyNames"
  doc-elem-form="HyDoc"
  bridge-form="hybrid"
  options="varlink loctype queryloc"
>
<!DOCTYPE MyDoc [
<!NOTATION Xpointer
   PUBLIC "http://www.w3.org/TR/1998/WD-xptr-19980303"
>
<!ATTLIST anchspec
  href
    CDATA
    #REQUIRED
  anchrole
    NAME
    #REQUIRED
  HyTime
    NAME
    #FIXED "anchspec"
  HyNames
    CDATA
    #FIXED "#ARCCONT href"
  loctype
    CDATA
    #FIXED "href QUERYLOC Xpointer"
>
]>
<MyDoc>
<varlink linktype="defined-as">
<anchspec 
  anchrole="mention" 
  href="#id(some-element-id)"
/>
<anchspec 
  anchrole="definition"
  href="#id(some-other-element-id)"
/>
</varlink>
<deflist>
 <dlentry id="some-other-element-id">A red or green fruit</dlentry>
</deflist>
 ...
<p>An <defined-term id="some-element-id">apple</defined-term> is often
used as a symbol for teachers.</p>
</MyDoc>

The ilink (independent link) form, uses a single attribute, "linkends",
to address the anchors of the link. The linkends attribute must be
declared as "IDREFS" and must specify exactly one ID value for each
anchor role:

<defined-as 
  HyTime="ilink" 
  anchrole="mention defintion"
  linkends="some-element-id some-other-element-id"/>

Each ID in the value of the linkends attribute is paired with the
corresponding anchor role named by the anchrole attribute.

With ilink, if you want to address more than one object for a particular
anchor, you just use indirect addressing to turn a single ID reference
into a reference to multiple objects.  For this reason, ilink is usually
the least convenient syntax choice for hyperlinks.

Remember that each of these three syntax configurations for hyperlinks
define the same abstract model.  All three configurations are thus
semantically equivalent. Any hyperlink represented using one syntax can
be transformed into either of the other two syntaxes without loss of
meaning.  For example, you might use the hylink syntax for authoring but
transform it to the varlink syntax for delivery with Xlink-aware clients
or servers.


<Address HyTime=bibloc homepage="http://www.drmacro.com">
W. Eliot Kimber, eliot@isogen.com
Senior SGML Consulting Engineer, Highland Consulting
2200 North Lamar Street, Suite 230, Dallas, Texas 75202
+1-214-953-0004 +1-214-953-3152 (fax)
http://www.isogen.com (work)</Address>