RE: XSL 1.1 WD comment: The properties which may be attached to an FO.
Glen Mazza <grm7793 <at> yahoo.com>
2004-01-16 23:19:02 GMT
>>There is nothing non-conformant about an XSL FO tree
>>has any property on any FO, but if a non-inheritable
>>appears on an FO to which it doesn't apply, it will
>>effect--since "applying (to an FO)" is equivalent to
"having an effect (for that FO)".
It's easier for me to think in more precise terms of
what "applying (to an FO)" means, without concern for
the rationale the authors chose in declaring the
property applicable. Simply: A property applies to
an FO if and only if it is defined within the
specification to apply to it.
For example, for fo:color-profile , properties
"src", "color-profile-name", and "rendering-intent"
apply to it, because the spec says so:
The authors could choose to add, for whatever reasons,
the "voice-family" property under that listing in the
spec, and that property would then apply to it, even
though it would have no effect on the FO.
>But you are effectively asking the following
> If one has a non-inheritable property on an FO to
> property does not apply, and a descendant FO to
> property does apply references that property via a
> or from-nearest-specified-value() function call,
> is returned by that function call?
>I will pass this question on to the group. The
tricky thing is
>that these functions return the "computed value" of
>and I'm not sure if a property has a computed value
>property doesn't apply (but I'm not sure if it
>which is why I'll be asking others who are more
expert on the
>data model here).
5.1 appears to be the relevant section :
"For every property that is applicable to a given
formatting object, it is necessary to determine the
value of the property. Three variants of the property
value are distinguished: the specified value, the
computed value, and the actual value."
However, just as 5.1.4's statement, that the
inheritable properties can be attached to any FO, does
not contradict the fact that non-inheritable
properties may also be attached--the above statement
also does not rule out that (sometimes) non-applicable
properties may also need to be resolved.
Finally, I'm not certain either way, but you may wish
to "rescrutinize" the rule of allowing any property to
be attached to any FO. There may be good reasons for
requiring (or allowing) implementations to flag as an
error the attachment of non-valid, non-inheritable
properties to an FO. For one thing, it seems that the
current rule may end up forcing implementors to
support extremely obscure cases, and it could also
lead to poor stylesheet design, as users attach
properties anywhere and reference them by types of
functions that Peter has mentioned. But I'm hardly an
expert on this issue, just my thoughts!
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes