Re: Characterstic Specification

[Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Vivek Agrawala wrote:
> 
> What does it mean to "evaluate an expression with respect to two
> flow objects" ?  Is the evaluation of expressions in the DSSSL
> style language defined somewhere ?

I think that that section means that the return value of procedures like
(actual-c) and (inherited-c) are decided with respect to the value flow
object and the specification flow object. As you read on, you will see
that the specification flow object changes to the parent flow object
when you call (inherited-c) and the parent's characteristic
specification is evaluated. If the parent's characteristic specification
expression in turn calls (inherited-c) then the grandparent's
characteristic specification is evaluated in turn, with the grandparent
as the specification flow object. You walk up the tree like this, and
return values down until the final characteristic is computed for the
"value flow object."

This definition of specifications and values seems to me to be a way of
saying: "the function (inherited-c) returns the parent's value for c" in
side-effect free language that does not imply that the parent flow
object is something with state sitting around in space with a bunch of
values for every inherited characteristic.

> Also, are the terms "value flow object" and "specfication flow object"
> defined somewhere ?

They are basically defined in the section you quoted. The definitions
become useful in the description of (inherited-c).
 
> The mechanism for specifying semantics of user-defined characterstics
> seems to be implementation defined.
> When the standard refers to an 'implementation' does it include
> only the style engine, or also the backends ?

I don't think that the standard has a priviledged notion of "backend."
There are only "implementations". Note that I have had success using
user-defined inherited characteristics as a way of passing data from
flow object parents to children. In this case neither the style engine
nor the back-end care. Almost by definition any good example I cite is
going to be a little complex, because anything simple can be done
without characteristics. It can probably be proven that anything that
can be done by passing around characteristics can be done by
regenerating the value over and over again, but characteristics allow
you to avoid that regeneration. For instance:

(declare-characteristic funky-colors-font "-//DOESNT//REALLY MATTER//")

(element scroll (make scroll funky-text-font: 
			(really-complex-function 
				(attribute-string "funky-font"))))
			;; maybe rcf does some complex mapping from the attribute contents
			;; to actual font names involving MD5 signatures and relational
			;; databases

(element funky-text font-family-name: (inherited-funky-text-font))

Theoretically this could call the relational database several times but
in practice an implementation would probably just do a "lookup" of that
characteristic value on the scroll object. The fact that you have made
the reuse of this value *explicit* through the use of
(inherited-funky-text-font) means that this optimization can be easily
recognized.

> Jade's RTF backend currently supports some additional characteristics.
> I looked at the implementation, and it seems that the semantics are
> defined by the backend when it defines the FOTBuilder::Extensions. It
> is not clear to me how one defines that a certain charateristic is
> only available on a certain flow-object class.

All user-defined ("application") characteristics are inherited.
Inherited characteristics can be applied to all flow objects. For
instance, scroll objects have a "font-family-name" characteristic
despite the fact that only actual character flow objects really "need"
that characteristic. That is because it is an inherited characteristic.
Application-characteristics have that behaviour.

> Currently, the public ids for these characteristics are of the form:
>   "UNREGISTERED::James Clark//Characteristic::heading-level"
> Would it be possible to have more general public ids like,
>   "UNREGISTERED::James Clark//Characteristic::integer" ?
> The name of the characteristic is already available as the first
> argument to declare-characteristic.

I'm not sure what you are getting at. What is more general about the
second?

 Paul Prescod


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