But Jade goes beyond DSSSL-O (was "Re: Style vs. Transformation")

Subject: But Jade goes beyond DSSSL-O (was "Re: Style vs. Transformation")
From: Tony Graham <tgraham@xxxxxxxxxxxxxxxx>
Date: Thu, 5 Mar 1998 12:50:54 -0500 (EST)
At 5 Mar 1998 09:51 +0000, Richard Light wrote:
 > In message <Pine.LNX.3.95.980304194016.8095B-100000@xxxxxxxxxxxxx>, Jani
 > Jaakkola <jjaakkol@xxxxxxxxxxxxxx> writes
 > >IMHO,  Jade proves that the style language with SGML
 > >flow objects can have enough power and expressivity so that the
 > >DSSSL-transformation language isn't really needed. But i'm sure
 > >that not everyone will share this opininion.
 > However, Jade goes considerably beyond DSSSL-O in the facilities it
 > provides, by supporting:

I very nearly posted much the same thing but held off because the
combination of ECMAScript and the pattern part of construction rules
provides much of the same facilities.  It doesn't provide all of the
facilities but it's not as if they were all missing from XSL as
described in XSL-NOTE.

 > the math flow objects 

These are missing

 > lambda (including #!key) 

lambda is out of place in ECMAScript anyway

 > let, letrec, let* and named let 

ECMAScript will let you assign to variables

 > quasiquotation 

No comment

 > node-list-first 
 > node-list-rest 
 > node-property 

Is XSL doesn't give access to node lists, these are moot.

 > sgml-parse 

Useful for subdocuments, but XML doesn't allow SUBDOC.

Would also be useful for extracting and showing what is pointed to in
another document.

 > children 
 > descendants 

Rather than iterating over a node list, the wildcarding and the
under-described ability to put arbitrary scripts in <select
from="..."> make it relatively simple to create rules matching
specific elements.

 > attributes 

I haven't found an analogue in XSL-NOTE

 > follow 
 > preced 

Maybe there can be <select from="=follow(...)"> or just <select

 > data 

I haven't found an analogue in XSL-NOTE

 > select-elements 

The pattern rules described in XSL-NOTE provides a similar facility.

 > select-by-class 
 > node-list-no-order 
 > node-list=? 
 > node-list? 
 > node-list 
 > node-list-map 
 > node-list-length 
 > node-list-ref 
 > node-list-reverse 
 > named-node-list? 
 > named-node 
 > named-node-list-names 
 > named-node-list-normalize 
 > process-node-list 
 > node-list-address (argument restricted to a singleton node-list) 

Moot if no access to node lists

 > element-with-id 

process-element-with-id from the DSSSL style language (section 12.4.3)
is far more useful, but there's no indication that it is expected to
be in every XSL implementation.

 > empty-node-list 

Possibly moot

 > Without this lot, I think that it would be hard to use Jade even for
 > routine styling.  So I think we should be clear as to the query language
 > facilities that XSL will offer us.  Surely the Jade experience shows us
 > that the core query language and DSSSL-O just aren't enough?

It became much easier to use Jade for complex styling as more of these
were added to later releases.


Tony Graham
Tony Graham
Mulberry Technologies, Inc.                         Phone: 301-315-9632
17 West Jefferson Street, Suite 207                 Fax:   301-315-8285
Rockville, MD USA 20850                 email: tgraham@xxxxxxxxxxxxxxxx

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread