Re: XS: out of line links

Subject: Re: XS: out of line links
From: "W. Eliot Kimber" <eliot@xxxxxxxxxx>
Date: Sat, 24 May 1997 10:36:24 -0500
At 11:11 AM 5/24/97 +0700, James Clark wrote:
>At 20:33 23/05/97 EDT, lee@xxxxxx wrote:
>>In general, the ability to apply styles to selected regions of a document
>>seems important to me.  For example, if I add an annotation, perhaps I want
>>a little picture of a pencil in the margin.  I'd like to mark link ends
>>(whatever they end up being called -- I still like "airports" best) with
>>little icons too, perhaps, or underline them or whatever.  In HTML, the
>>starting point of a link is always marked explicitly with SGML containment,
>>so that applying a blue underline is easy, but in XML this isn't the case,
>>and another mechanism will be needed.


>>Another possibility would be to have flow objects representing out-of-line
>>links (maybe as part of the content of some sort of hyperdocument flow
>>object).  That would probaby require special inheritance rules (like for
>>table-column), so that you can (for example) get resources in a different
>>color.  But that's not enough to for example put a resource in a box.
>>Another possibility would be to do some link processing on the grove before
>>the DSSSL processor sees it which turns out-of-line links into in-line links
>>(maybe using a special-purpose node-class).

In a HyTime system that supports unrestricted independent (out-of-line)
links, you would have a hypergrove that includes the groves for all the
documents you know about (the "bounded object set" or BOS) as well as the
HyTime semantic grove, which represents the result of applying HyTime
processing semantics to the hypergrove.  Among other things, it reflects
all the hyperlinks in the hyperdocument.  As it is a grove, you should be
able to use DSSSL to query the grove and determine whether or not a given
node in a document is also a member of any hyperlink anchors.  This is the
way my ADEPT*Editor HyTime code works: I build the functional equivalent of
the HyTime semantic grove in memory and then for each node in ADEPT's
document tree, I can determine if it is a member of any anchors.

I'm not sure I understand the need for additional flow objects in this
case: the determination of anchor (resource) ness would be done at the time
an node is processed, not at the time the FOT is processed, right?

Of course, this processing model isn't the only way to implement
independent links--for example, you might not make links "active" until the
document that contains them (the link elements, not their anchors) is
traversed to, so that you don't have to process the entire BOS before you
can make any links active.  In this case, the determination of linkness of
objects in documents already processed would occur after their FOTs have
been created, suggesting that the anchor presentation mechanism would be
controlled outside the main style spec for the document, if not outside
DSSSL-based processing entirely.

And don't forget that you need to be able to condition the presentation of
anchor objects based on the anchor role and link type, not just on their
own context.  This can mean, for example, that the presentation of an
object can change based on which links of which it is an anchor member are
"active" (where making links active may be a user choice based on link
types, e.g. "make all "edit" links active and make all "comment" links
inactive", where "edit" link anchors are presented one way and "comment"
link anchors presented another (say different icons or text colors).)  How
does a DSSSL-based system represent this sort of dynamism?  I assume that,
conceptually, it would do so by creating a new FOT every time the state of
active links changed, although in practice you would really just modify the
one you already have (if possible). [In other words, at the conceptual
level, groves are static and when the grove source changes, conceptually
you create a new grove, even though under the covers you may be just
modifying those nodes that actually changed, as you would in an editor.]



 DSSSList info and archive:

Current Thread