XLink/XPointer Developer's List

[W. Eliot Kimber]

At 09:40 AM 12/2/98 -0500, Simon St.Laurent wrote:
>harden, deserve their own space.  I'd like to see some members of the
>HyTime community who haven't been working full tilt with XML join the
>discussion, 

I actually don't know of anyone I would consider part of the HyTime
community that hasn't been heavily involved with XML in one way or another
(although I can't claim we've all been working "full tilt", although many
of us are or have been). Certainly all the editors of the standard have
been, as have long-time users like Lloyd Harding (SMIL), Michel Biezunski
(Topic Maps), and Martin Bryan (XML EDI, Topic Maps). Fujistu (HyBrick) has
been a long-time user of HyTime and an early implementor of Xlink/Xpointer.
 Steve DeRose of course is the editor of the Xlink and Xpointer specs.  I
personally did a partial implementation in DSSSL
(<http://www.drmacro.com/hyprlink/xlink/>).

And, of course, I subscribed to the new mailing list immediately.

XLink and XPointer are very important to HyTime because they provide
exactly what HyTime has always needed: a simple but useful application of
the HyTime ideas that makes it clearer what the benefits of a more
sophisticated approach to hyperlinking are.  My experience in teaching
XLink is that people get it pretty fast, they start to see the potential in
things like extended links and addressing of non-IDed things. They then see
why HyTime is the way it is and see that XLink/XPointer provides a
migration path for them such that when and if they reach the limit of what
XLink and XPointer can do, they can start taking advantage of additional
HyTime facilities without affecting their existing documents and software,
because XLink and HyTime are syntactically and semantically compatible.

By itself, XPointer is very useful to HyTime because it provides a very
convenient addressing syntax that it was not practical for HyTime to
provide directly (simply because we only had so much time to develop the
standard and focused on the more general facilities--also defining a
convenient syntax is much more difficult than defining a complete one
because of the compromises that must be made to balance ease of use with
functionality).  

Because HyTime is defined entirely in terms of operations on groves, HyTime
can be used with any addressing mechanism as long as the results of that
mechanism can be defined in grove terms.  This is trivial for XPointers
since they are already defined in terms of XML.  One of the reasons I did a
DSSSL-based implementation of XPointer is that it becomes the mapping of
XPointer semantics onto the grove formalism, and in particular, the SGML
document grove defined by the SGML property set (this is because DSSSL is
also defined in terms of operations on groves).  So XPointers are entirely
meaningful and sensical within a HyTime environment.

One interesting aspect of using XPointers within a HyTime environment is
that you get indirection, which XLink/XPointer currently doesn't provide
(and probably shouldn't provide if it hopes to stay sufficiently
simple--indirection adds a significant amount of complication and
implementation difficulty).  

For example, the following indirect address combines normal HyTime syntax
with XPointers to provide what is essentially a table of named XPointers:

<?xml version="1.0"?>
<?IS10744 arch name="HyTime"
  public-id="ISO/IEC 10744:1997//DOCUMENT Hypermedia/Time-based Structuring
Language (HyTime)//EN"
  doc-elem-form="HyDoc"
  renamer-att="HyNames"
  options="queryloc"
  auto="arcauto"
?>
<!DOCTYPE LocTable [
 <!NOTATION XPointer 
   PUBLIC "http://www.w3.org/TR/WD-xptr"
 >
 <!-- Indirect address for using XPointers. Declared here to avoid
      instance specification of fixed attributes from HyTime
      architecture.
   -->
 <!ATTLIST XPointer-loc
   id
     ID
     #REQUIRED
   href
     CDATA
     #REQUIRED
   HyTime
     CDATA
     #FIXED "queryloc"
   notation
     NOTATION 
     (XPointer) "XPointer"
   HyNames
     CDATA
     #FIXED "#ARCCONT href"
 >
]>
<LocTable>
<desc>Document containing a set of indirect addresses for use
by reference from other documents.  Makes addresses easier to
manage. Can think of it as a "public API" to a document that
associates names with unnamed objects (elements addressed by
position).
</desc>
<XPointer-loc 
  id="child-3"
  href="http://some/url#root().child(3)"/>
<XPointer-loc 
  id="child-4"
  href="http://some/url#root().child(4)"/>
</LocTable>

This document can then be used by reference from other HyTime documents:

<?xml version="1.0"?>
<?IS10744 arch name="HyTime"
  public-id="ISO/IEC 10744:1997//DOCUMENT Hypermedia/Time-based Structuring
Language (HyTime)//EN"
  doc-elem-form="HyDoc"
  renamer-att="HyNames"
  options="varlink queryloc refloc"
  auto="arcauto"
?>
<!DOCTYPE linkgroup [
 <!NOTATION XPointer 
   PUBLIC "http://www.w3.org/TR/WD-xptr"
 >
 <!-- Anchor specification element: corresponds to XLink locator -->
 <!ATTLIST anchspec
    anchrole
      CDATA
      #REQUIRED
    href
      CDATA
      #REQUIRED
    HyNames
      CDATA
      #FIXED "#ARCCONT href"
    HyTime
      CDATA
      #FIXED "anchspec"
    loctype
      CDATA
      #FIXED "href QUERYLOC XPointer"
    xml:link
      CDATA
      #FIXED "locator"
    xml:attributes
      CDATA
      #FIXED "role anchrole"
 >
]>
<linkgroup xml:link="group">
<varlink linktype="compare" xml:link="extended">
<desc>
An out-of-line ("independent") extended link that associates two things in
order to suggest that they compare to each other in some way.
</desc>
<anchspec 
    anchrole="thing-one" 
    href="loctable.xml#id(child-3)"/>
<anchspec 
    anchrole="thing-two" 
    href="loctable.xml#id(child-4)"/>
</varlink>

Here, I've shown the mapping between the HyTime variable link (varlink)
form and the XLink extended form, even though an XLink processor would not
resolve the indirection of the elements in the location table document
(because XLink doesn't define any indirection mechanism). In other words,
HyTime sees these documents as linking the third child of "/some/url" to
the fourth child, while XLink sees these documents as linking the queryloc
"child-3" to the queryloc "child-4". This is because a HyTime engine will
resolve all the indirect addresses when it determines the anchors of the
link, but an XLink engine will not.

Note that the processing required by the HyTime engine is significantly
greater than the processing required by the XLink engine, which is one
reason why XLink doesn't (and probably shouldn't) require indirection.
Unfortunately, from an authoring perspective (as opposed to a delivery
perspective), indirection is pretty much a requirement in order to make
addresses managable within a dynamic information base.  Thus, it's likely
that people will use indirection (and thus HyTime) while authoring and then
convert the indirect addresses to direct XPointers for delivery.

Cheers,

E.

Cheers,

E.


--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

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