Peter B. West wrote: > Glen Mazza wrote: > > --- "Peter B. West" <[EMAIL PROTECTED]> wrote: > > > >>See above. In alt.design, all compounds are > >>shorthands, and all > >>shorthands are presumed to have been resolved into > >>their components > >>during FO Tree building. > >> > > > > > > BTW, does Alt-Design already resolve the cases where > > *both* a shorthand and one of its included components > > are specified? I.e., (usually, I believe), disregard > > the shorthand value for that component and use its > > explicitly given value instead? > > > > It's in the ordering of the properties. There is a simply for loop to > process properties (attributes, in fact) defined on an FO. The order of > definition ensures the correct order of evaluation - shorthand first, > then any individual properties. The same goes for corresponding > properties, when I get around to doing them. Check the order of > properties in PropNames.java.
I don't know how to reconcile this with your previous posting: > See above. In alt.design, all compounds are shorthands, and all > shorthands are presumed to have been resolved into their components > during FO Tree building. The previous posting seems to indicate that the properties have been decomposed, the chronologically latter posting seems to indicate that the shorthand retains its shorthand character. The critical thing here is that the API not even allow anybody to ask about shorthand or compound properties. The API should allow requests only for the decomposed properties, and the FO Tree should resolve all of this before passing a value back. Victor Mote
