Re: unmarked linkend awareness by XML engines
I agree with Martin Bryan that SDIF is irrelevant to this discussion.
The BOS concept, however, is very relevant. It is a way of limiting
the number of links for which an application is responsible. It gives
an application much more power to make information useful and
accessible, by limiting the amount of information over which such
power must be exercised.
> No, we simply have to face the fact that end users are the only ones
> who can decide what documents need to be in their processing set.
Right. But that doesn't mean users won't find it valuable to have an
author's *suggested* BOS on hand. On the contrary, most serious users
of documents are delighted to have the document's author provide all
> Other links to that document will only be found if the user has
> explicitly or implicitly (via some strategy) specified what other
> documents may contain ilinks of interest (for example by opening a
> bookmark set of ilinks, or a guided tour set of ilinks, or an
> annotation set of links, etc.).
But, then, we agree! This is precisely what a BOS does; it's a
> We can't check the whole world, and we can't just leave it to the
> author (without damaging the ability to create external
> annotations), so we have to leave it to the user (via their
I strongly agree with you, but you evidently think I disagree. I
think maybe you're making a false assumption about what I'm proposing.
According to HyTime, the BOS *suggestion* presumably takes effect when
the user begins a session by entering a particular document. Nothing
requires that the user accept the document author's suggestion.
Indeed, if the user insists on making the whole Web the BOS of his
session, he can sit there and wait until his beard hits the floor.
Far be it from HyTime to stop him from engaging in such folly,
however. That session-start document contains the suggested BOS
expressed as a set of <!ENTITY declarations with arbitrary limits on
how deeply those entities can recursively declare other entities which
will become part of the BOS. The resulting pruned entity tree
contains all the links for which the HyTime application is recommended
to be responsible by the author of the session-start document.
If, in the course of traversing the links in the session-start
document, the user encounters another document, the user certainly has
the option of accepting *that* document's suggestion as to what the
BOS should be (making that document effectively the session-start
document), or, of adding that document's BOS to his existing,
session-dependent BOS, or of simply ignoring the suggestion and
keeping the present BOS, or of doing something else entirely.
The existence of a BOS suggestion *enables* ilinks by making them
practical and scalable, which in turn *enable* the creation of
annotations of read-only materials which can be seen in the context of
the read-only document. If the user begins his session with the
annotation document and traverses to the annotated document, because
the annotation document is necessarily in the user's BOS, all the
annotations in the annotation document can then be made available by
the application as hot links from within the annotated (read-only)
document. (I don't need to point out that you can't do this with
HTML, or that that is one hell of a useful capability.)
> We may well want to consider adding additional notations to express
> that some document _may_ be processed when a document is
> processed. Sort of a "This document best when parsed along with ..."
How is this different from HyTime BOS notation? I don't see any
difference, Dave. I think we're actually on the same side of this
Let me again rephrase the question I want answered:
"Do we want XML to be able to make hot links available in documents
when those documents do not themselves contain those hot links?"
It's do-able if we have, as Dave puts it, "additional notations to
express that some document _may_ be processed when a document is
processed." Or, as HyTime puts it, the bounded object set (BOS)
Steven R. Newcomb President
voice +1 716 271 0796 TechnoTeacher, Inc.
fax +1 716 271 0129 (courier: 23-2 Clover Park,
Internet: firstname.lastname@example.org Rochester NY 14618)
FTP: ftp.techno.com P.O. Box 23795
WWW: http://www.techno.com Rochester, NY 14692-3795 USA
P.S. FYI, in HyTime jargon, the session-start document is called the