Re: DSSSL Design Question

Subject: Re: DSSSL Design Question
From: "James Clark" <jjc@xxxxxxxxxx>
Date: Wed, 18 Jun 1997 13:07:30 +0700
> From: Vivek Agrawala <vivek@xxxxxxxxxxxxxxx>
> To: dssslist@xxxxxxxxxxxxxxxx
> Subject: Re: DSSSL Design Question
> Date: Wednesday, June 18, 1997 4:33 AM
> 
> James Clark wrote:
> >
> > Since you can declare your own characterstics, why aren't they
sufficient?
> > 
> > I think it would desirable to allow #f instead of a public identifier
in
> > declare-characteristic, to mean that this isn't a characteristic that
has
> > semantics that should be passed to the formatter, but rather it's just
being
> > used to pass information down.
> 	I like this idea. It would improve the flexibility of DSSSL.
> 
> 	Can such characteristics be handled completely by the implementation?
> 	With the current Jade, user-defined characteristics require
> 	some modification in the backend(s).

At the moment if you declare a characteristic with a public identifier that
Jade doesn't know about, you can still use it to pass information down. 
This is just a convenience to make to clear that you don't intend there to
be any formatting semantics associated with the characteristic.
 
> What are the advantages of "First Class Modes" over the
>  "Not For Formatter Characteristics" ??

You can only use inherited-c inside the specification of a characteristic. 
It's not legal to do something like:

(element p
  (if (equal? (inherited-foo) 'bar)
     (make paragraph)
     (make sequence)))

This is because inheritance works on the flow object tree, and outside of a
characteristic specification you don't know where you are in the flow
object tree.

On the other hand there's no such restriction with first class modes.

James




 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist


Current Thread