<-prev [Thread] next-> <-prev [Date] next->
Month Index | List Home

Re: dl/dt/dd matching

Subject: Re: dl/dt/dd matching
From: Oisin McGuinness <oisin@xxxxxxxx>
Date: Thu, 14 Jan 99 08:30:41 -0500
The original problem (Francois Belanger <francois@xxxxxxxxxxx>,  Mon, 11 Jan 99 18:12:31 -0500)
was how to transform:

<dl>
<dt>Term 1</dt>
<dd>Description 1</dd>
<dt>Term 2</dt>
<dd>Description 2</dd>
</dl>

into:

<TABLE>
<TR>
     <TD>Term 1</TD>
     <TD>Description 1</TD>
</TR>
<TR>
     <TD>Term 2</TD>
     <TD>Description 2</TD>
</TR>
</TABLE>

There have been several interesting replies, in particular by Paul Prescod
pointing out that changing the DTD (would architectural processing help if
one can't change the DTD, as in the Voyager case?) to give a wrapper element DLITEM
would make the problem easier. 

Also James Clark commented:
> 
> Francois Belanger wrote:
> >
> > I'm scratching my head on this one.
> 
> I've been scratching my head for years on this one.  It's a problem in
> DSSSL too.

At the risk of pointing out the obvious, the solution is fairly easy in DSSSL. All one has
to do is not have explicit rules trigger for handling DT and DD elements, and have the
handling of the DL element explicitly get the DT and DD children, and do the right thing.
Here is the style sheet. (Note that I use the Jade extensions of James Clark to handle
the element generation, but the collection and processing of the nodes is core DSSSL.)
There is a certain amount of boiler plate needed to make the example complete.

cat test.dsl

<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" >
<style-sheet>
<style-specification id="SBCM-test">
<style-specification-body>

;; We need Jade extensions for element creation, for HTML output.
(declare-flow-object-class element
  "UNREGISTERED::James Clark//Flow Object Class::element")
(declare-flow-object-class empty-element
    "UNREGISTERED::James Clark//Flow Object Class::empty-element")
(declare-flow-object-class document-type
      "UNREGISTERED::James Clark//Flow Object Class::document-type")
(declare-flow-object-class processing-instruction
	"UNREGISTERED::James Clark//Flow Object Class::processing-instruction")
(declare-flow-object-class formatting-instruction
	  "UNREGISTERED::James Clark//Flow Object Class::formatting-instruction")

;; Make the default simple.
(default (process-children))

(element HTML
	(make sequence
	;; Generate a DOCTYPE element.
	(make document-type
		name:           "HTML"
		public-id:      "-//W3C//DTD HTML 3.2//EN")
	(make element gi: "HTML"
		(process-children))))

;; BODY, HEAD, TITLE, handle identically.
;; We don't bother with copying attributes here.
(element BODY
	(make element gi: "BODY"
		(process-children)))
(element DIV
	(make element gi: "DIV"
		(process-children)))
(element HEAD
	(make element gi: "HEAD"
		(process-children)))
(element TITLE
	(make element gi: "TITLE"
		(process-children)))

;; Do nothing explicit for DT and DD's
(element DT (empty-sosofo))
(element DD (empty-sosofo))

;; Generate table entry elements.
(mode plain-table-entry
	(element DT (make element gi: "TD" (process-children)))
	(element DD (make element gi: "TD" (process-children))))

;; Generate a table from a DL, with appropriate processing.
(element DL
	(make element gi: "TABLE"
		(process-dt-and-dd-children)))

;; We want to generate table rows for each DT and DD pair.
;; The current node is a DL.
(define (process-dt-and-dd-children)
	(let loop (
		(dt-children (select-elements (children (current-node)) "DT"))
		(dd-children (select-elements (children (current-node)) "DD")))
		(if (node-list-empty? dt-children)
			(empty-sosofo)
			(make sequence
				(make element gi: "TR"
					(sosofo-append
					(with-mode plain-table-entry
						(process-node-list (node-list-first dt-children)))
					(with-mode plain-table-entry
						(process-node-list (node-list-first dd-children)))))
			(loop (node-list-rest dt-children) (node-list-rest dd-children))))))

</style-specification-body>
</style-specification>

</style-sheet>

Here is the input test.html file:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Test File</TITLE>
</HEAD>
<BODY>
<DIV>
<dl>
<dt>Term 1</dt>
<dd>Description 1</dd>
<dt>Term 2</dt>
<dd>Description 2</dd>
</dl>
</DIV>
</BODY>
</HTML>

And the output test file:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML
><HEAD
><TITLE
>Test File</TITLE
></HEAD
><BODY
><DIV
><TABLE
><TR
><TD
>Term 1</TD
><TD
>Description 1</TD
></TR
><TR
><TD
>Term 2</TD
><TD
>Description 2</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>

while the jade command line is just:

jade -c catalog -d test.dsl -t sgml test.html > test-out.html

with the catalog file being pretty standard.

The point here is that, *personally speaking*, it seems to me that 95% or greater
of the problems that are posed on this list with regard to using XSL, in each of the
different draft forms, to solve various problems, are either straightforward in DSSSL, have
a much more natural syntax in DSSSL (parentheses are your friend, after a little while), or 
are solvable with a good library of DSSSL functions or conventions to handle things like Xpointers.

The only major improvement of XSL over DSSSL (in conciseness, but not
expressiveness) seems to be in the matching of elements meeting various conditions.
And it seems to me that sooner or later, one is going to want to find elements with conditions
that are not easily met, where one wants to choose elements based on a little
computation. In such situations, the node-list-filter function in DSSSL is immensely useful.
What is the analogue in XSL, if one has no access to a scripting language?

I would also like to say that I find the XSL mixture of code and data very confusing to read, e.g., in
this piece taken from a reply by Belanger to the comments on the original post:

<xsl:template match="dt|dd">
    <td>
      <xsl:apply-templates/>
    </td>
</xsl:template>

the pieces of text that "look like tags" <xsl:....> are "code", while the pieces of
text that "look like tags" <td> and </td> are "data" to be passed through to the output
document. 
Am I the only one blocking on this, or is it something that gets easier with familarity?

So the question I have for those who know or use both XSL and DSSSL, is what would
I (or the world) gain from using XSL instead of DSSSL, apart from the promised
browser support by at least 1 major corporation? What are the other benefits?

I'm not trying to start a flame war, just hoping for some clear reasons to invest
more effort in XSL, as opposed to continuing work in DSSSL.

Thanks for reading this long post.

Oisin McGuinness

Sumitomo Bank Capital Markets
277 Park Avenue
New York NY 10172
USA


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
Current Thread
<- PreviousIndexNext ->
Re: dl/dt/dd matching, Henry S. Thompson Thread RE: < in <xsl:eval>, David Schach
Re: Existing XSL processors, James Tauber Date Mixed content transformation, Paul_Tihansky
Month