But given that your browser provides a way to do the association, the task
is to *create the Java classes*, which is conceptually identical to
creating a style rule in a DSSSL or XSL specification, although the details
of the specification are of course different.
Style sheets are nothing more than a mostly-declarative form of program.
Here's how I would insert a "button" into the display of a document using
DSSSL and HyBrick:
(element simple ; Rule for any Xlink <simple> element
(make link destination: (resolve-location-address
(attribute-string "HREF" (current-node)))
(make external-graphic entity-system-id: "buttons/clickhere.gif"
notation-system-id: ""))))
With Java, I might have a button class that I map elements of type "simple"
to, but the result would be indistinguishable from the above (all other
things being equal).
Providing a sexier type of button would require support within the
presenation system for them. For example, say my online DSSSL renderer
supports program objects as a notation for external graphics. I could do
this:
(element hyperlink
(make link destination: (resolve-location-address
(attribute-string "HREF" (current-node)))
(make external-graphic entity-system-id: "{BACD-0000-0000-BCDEF-00}"
notation-system-id: "WINCOM"))))
Now my button will be a program object rather than a static graphic, but
notice that the style definition has not otherwise changed--I've just taken
advantage of some facility of my presentation system.
Another alternative would be to define a new flow object class that
provides the interactive features you want. Say, for example, you want a
button that will appear to push. We (as a community or as a set of
developers) could define a new flow object class called, for example,
"interactive-button":
(element hyperlink
(make link destination: (resolve-location-address
(attribute-string "HREF" (current-node)))
(make interactive-button
behavior: 'push ; Alternatives might be rollover, flash, etc.
image-system-id: "buttons/clickhere.gif")))
Now we've abstracted the idea of "button" in a way that can be reasonably
interchanged and implemented in a variety of ways. The degree to which it
is interchangable is the degree to which different providers of DSSSL-based
rendering systems implement it.
I've used DSSSL syntax because that's what I know, but the same approach
should apply to XSL as well (at least to the degree that XSL supports the
definition of new flow object classes, which it may or may not, I don't know).
Cheers,
E.
-- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com </Address>