From owner-xml-dev@ic.ac.uk Wed Dec 2 10:26:21 1998 Date: Wed, 02 Dec 1998 09:51:08 -0600 To: xml-dev@ic.ac.uk From: "W. Eliot Kimber" <eliot@dns.isogen.com> Subject: Re: XLink/XPointer Developer's List
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@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)