Subject: Re: Characterstic Specification From: Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx> Date: Mon, 19 May 1997 16:15:40 -0400 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Characterstic Specification, Vivek Agrawala | Thread | Re: Characterstic Specification, Vivek Agrawala |
Re: SGML/XML syntax for DSSSL-Web, Paul Prescod | Date | Side-effect freedom (Re: When trans, Vivek Agrawala |
Month |