W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > January 1997

Re: Radical cure for BOS confusion

From: Michael Sperberg-McQueen <U35395@UICVM.UIC.EDU>
Date: Thu, 09 Jan 97 15:16:25 CST
Message-Id: <199701092135.QAA29367@www10.w3.org>
To: W3C SGML Working Group <w3c-sgml-wg@www10.w3.org>
On Mon, 6 Jan 1997 15:51:41 -0500 Jon Bosak said:
>For hlinks (nee ilinks) -- here comes the radical part -- we could
>take Dave Durand's "companion document" idea to a logical extreme.  We
>could define a special document type (i.e., provide a standard DTD)
>for something called, say, "linkset" that is nothing but a collection
>of hlinks (plus whatever other linking/addressing stuff we find useful
>to put in there).  In doing so, we would entirely eliminate the idea
>that ordinary documents could contain hlinks; they could only contain
>alinks.  Then linksets (collections of hlinks) would exist for just
>one purpose: the creation and management of links that stand outside
>of individual documents.  ...

>Intuition tells me that this must be too simple, but I would very much
>like to know why.  What's wrong with this picture?

The main thing I see wrong with it is that there are large portions of
the Western cultural tradition, and I believe even larger portions of
the Eastern tradition, which may plausibly described as documents whose
main purpose is to establish, describe, annotate, and discuss links
between other documents.  Imagine a book on -- say -- the history of
Bible translations, which in the course of its argument makes a number
of point-by-point comparisons between the Vulgate and Erasmus's
translation, or among Wycliffe, AV, RSV, NEB, and NIV.  It does not seem
to me unnatural for a reader of any of these Bibles to wish the browser
to underscore in blue whatever passages are mentioned in the book's
commentary, or to wish to traverse those links to see what the book
says about those passages.

The encoder of the book on translation can, of course, evade our
prohibition on ilinks in normal documents, by adding one more link end
and saying (disingenuously) "This is not a two-way link between Jerome
and Erasmus; it's a three-way link among Jerome, Erasmus, and my
commentary on the two."  (In some cases, this will be accurate, but we
can say it even if it's not, to avoid the prohibition on ilinks in
normal documents.)

Now the links are legal in the book on translation.  How do I tell my
browser "Please open the Vulgate, and load also all the external links
pointing in to it from the book on translation" if the pointers at the
head of the Vulgate are allowed only to point to linksets of ilinks and
not to other ordinary documents?

I think the key simplification of Jon's proposal lies in saying the XML
BOS (by which I mean set of documents for which the browser is
responsible, in the sense of scanning them for links pointing into the
document currently on view) may be given explicitly in the document
itself.  I think both David Durand (who like Jon wishes to divorce this
specification from the entity declarations at the head of the document)
and Steve Newcomb (who does not, as far as I have been able to follow),
will agree this is a Good Thing.

Restricting the XML BOS to specialized ilink documents, and saying that
the browser is responsible for detecting only incoming ilinks, not
incoming alinks, does not seem to me to be a material simplification.
For practical reasons, documents containing nothing but ilinks (with a
little metadata) may be useful sometimes in reducing bandwidth needs,
but that doesn't make them conceptually simpler than allowing ilinks in
ordinary documents.

In sum:
  - prohibition of ilinks in normal documents seems unnecessary and
  - prohibition of ilinks in normal documents is easily evaded anyway
  - ilinks are not the only kind of external link I'd like my browser to
know about:  I'd also like to be able to know which portions of the
document I'm reading are targets of alinks from other documents I am
interested in -- so I want to be able to include ordinary documents
in the XML-BOS.

-C. M. Sperberg-McQueen
Received on Thursday, 9 January 1997 16:35:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:06 UTC