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.] Cheers, E. DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
XS: out of line links, James Clark | Thread | Re: XS: out of line links, James Clark |
Re: XS: Ports --> math, Paul Grosso | Date | Re: SDATA entity mapping, Stephen J. Tinney |
Month |