Homegrown versions of standard DSSSL operations

Subject: Homegrown versions of standard DSSSL operations
From: Tony Graham <tgraham@xxxxxxxxxxxxxxxx>
Date: Sun, 6 Apr 1997 00:11:10 -0500 (EST)
It is a temporary condition, but Jade does not yet provide the full
set of SDQL operations (those defined in section 10 of the standard).
Last week Bill Lindsey provided his versions of preced, siblings, and
empty-node-list (which is included in Jade 0.6), and Paul Prescod
mentioned he had implemented preced and ipreced.

One of the aims of this list is to leverage the knowledge of DSSSL
users, so do people have their own versions of the SDQL functions that
they can make available in the interim until they are included in the

If you are able to provide the definition for a SDQL operation, I
suggest a format similar to the following that also lists the
prerequisites for the operation, in this case those operations
provided by Jade 0.6 plus the "siblings" operation:

;; (sdql-operation parameter)
;; Author: Tony Graham <tgraham@xxxxxxxxxxxxxxxx>
;; Requires: Jade 0.6 + siblings
(define (sdql-operation parameter)

If there is sufficient response, I will put the collected definitions
on the web page.


Tony Graham
Tony Graham, Consultant
Mulberry Technologies, Inc.                         Phone: 301-231-6931
6010 Executive Blvd., Suite 608                     Fax:   301-231-6935
Rockville, MD USA 20852                e-mail: tgraham@xxxxxxxxxxxxxxxx

At 18:50 02/04/97 +0200, Norbert Mikula wrote:
>How would we specify the mapping of XML-LINK to a
>DSSSL style-specification. Would we need to use
>an external procedure ? 

There are a number of things that are needed.

- - There needs to be a url-address external procedure, that takes a string
and a singleton node-list (defaulting to the current node).  The node-list
is needed to handle relative URLs.  The string would include the fragment
identifier (the part after the #).

- - There needs to be a mechanism to handle the XML TEI xpointer-based
fragment identifier syntax.  This isn't something that needs to specified in
the style spec (except for SHOW=EMBED).  The meaning of the fragment
identifier is determined by the content type of the URL.  When an XML
browser fetches a resource and find that it's XML, then it needs to
interpret any fragment identifier as the XML spec requires and then go to
the specified place.  This is more a browser interface issue than a
stylesheet issue.

- - For the case of SHOW=EMBED, the referenced resource should be part of the
same flow object tree.  When it's a non-XML resource, we can handle that
with an external-graphic flow object.  When it's an XML resource, we need to
do something like

  (process-node-list (tei-xpointer (sgml-parse url) fragment-id))

Maybe to start with we would only support this when the URL is empty (ie an
xpointer into the same document).

Providing TEI xpointer support in DSSSL would probably best be done in two
parts.  Firstly a function that takes a string representation of a TEI
xpointer (either the the XML version or the original TEI version) and
returns an S expression representation.  Secondly a function that takes a
node-list and an S expression representation of the xpointer and returns
another node-list, eg

  (tei '(here ancestor (1 P) previous (1 P)) (current-node))

- - There needs to be a characteristic on the link flow object to deal with

- - Finally there needs to be some way to deal with out-of-line links (HyTime
ilinks).  How does a stylesheet know to make a link flow object for an
element that is specified to be a resource of an out of line link?  It is
not obvious to me what the right approach here is.

One possibility would be something like

(default (if (xlink-resource? (current-node))
             (make link
                   destination: (xlink-address (current-node))

That's not going to work if you have out-of-line links into character data.

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).


Current Thread