Stylesheets considered limiting (was Re: XLink - where are we?)

[W. Eliot Kimber]

At 08:53 AM 11/12/98, Peter Murray-Rust wrote:
>>are no different from requiring a style sheet--someone still has to provide
>>a per-document or document type definition of what the styling should
>>be--whether you use Jave code or DSSSL specs or XSL doesn't matter--the
>>task is the same.
>
>Nope. In Java the task for me is:
>	- to identify how to map Java classes onto elements. I haven't followed
>XSL but I assume it gives little or no help. 
>	- how to create different on-line displays interactively. I'd like to
>insert buttons where there are hyperlinks, for example. Is all that in XSL.

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>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)