anchor awareness (was Re: Richer & richer semantics?)
Subject: anchor awareness (was Re: Richer & richer semantics?)
From: "Steven R. Newcomb" <email@example.com>
Date: Sat, 21 Dec 1996 18:08:53 -0500
From firstname.lastname@example.org Sat Dec 21 18: 06:59 1996
In-reply-to: <199612211815.KAA20527@ishtar.fsc.fujitsu.com> (message from Terry Allen on Sat, 21 Dec 1996 10:15:10 -0800 (PST))
Terry Allen <email@example.com> writes:
> But if this group can find a way to construct links such that
> the server of the transcluded object can detect that it's being
> fetched for the purpose of transclusion, that would be an
> immense win. Awesome, even.
> Xanadu evades this matter by assuming that everyone has already
> signed on to a copyright protection and micropayment scheme.
> The real world is, of course, different.
Please bear with me to the end of this harangue, because it's relevant
to several topics. I think Terry's remark highlights a key issue.
A embryonic general solution to Terry's question, "Activity Policy
Association," exists in HyTime. The fundamental idea is simple
enough: you have a statement of the owner's policy -- a license
statement -- which is unambiguously attached to the information. (In
HyTime, the statement could be, in fact, an applet which enforces the
policy, but I'm not proposing that XML endorse that refinement.) The
licensed information serves as an anchor of what, in effect, is a
special kind of link to an object that expresses the policy.
And here is where we see a more fundamental issue that is relevant to
the whole discussion of hyperlinking in XML. The question is:
"Does an anchor know that it is an anchor?"
The answers to lots of important questions depend on the answer to the
above question, including:
"Can an n-ended link be n-directional?" ( n >= 2, of course )
"Can a link appear elsewhere than any of its anchors?"
"Can metadata (such as activity policies) be associated and
re-associated with data without changing the data?"
This question should not be easy for any voting member of the ERB to
decide. Frankly, I don't know how I would vote; at this point I'd
have to wait and see what came out of the discussion.
On the one hand, if we say that anchors must be aware of their
anchorishness even when the links that confer anchor status upon them
are elsewhere, a many-headed Hydra monster arises. HyTime and the
HyTime TC1, and DSSSL (especially with its grove notion) offer some
cool answers for dealing with that monster that really work. But
these concepts are hard to explain and hard to understand, and they
scare implementers who haven't lived with the underlying ideas for
awhile. For most people, they're extremely challenging ideas,
frankly: as challenging as the object-oriented paradigm (which is
mainly what it *is*, in fact). Even so, having lived intimately with
the problem and discussion of anchor awareness and its implementation
for years, I have this not-so-clever insight to share:
Either we accept a basic paradigm change in the way we handle and
think about pretty much every component of documents (i.e., we move
to the grove paradigm), or we can't really implement anchor
Sobering, isn't it?
On the other hand, if (as in HTML) we say that all linking is
unidirectional and all links have two ends, the starting end of which
is where the link is, XML does not offer any functional improvement,
in hyper terms, over HTML. That's OK, and we won't have to go on a
Hydra-slaying mission, but I think there's a huge problem with this
alternative, too. Will people switch from HTML to XML just because
they get the totally intangible and abstract benefit of arbitrary
structure and generic markup? I think, in most cases, not. It won't
matter that XML is better for the long term if there's no compelling
reason to switch over to it. A radical improvement in
hyperfunctionality would, I think, certainly provide a compelling
reason and turn the tide. I'm not sure what else, if anything, could
do that as powerfully or certainly.
God bless us, every one. <<-- Seasonal greeting doubly appropriate.
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