RE: XSL 1.1 WD comment: The properties which may be attached to an FO.

-----Original Message-----
>>There is nothing non-conformant about an XSL FO tree
that
>>has any property on any FO, but if a non-inheritable
property
>>appears on an FO to which it doesn't apply, it will
have no
>>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 [1], properties
"src", "color-profile-name", and "rendering-intent"
apply to it, because the spec says so:

http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo_color-profile

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
question:

>  If one has a non-inheritable property on an FO to
which that
>  property does not apply, and a descendant FO to
which that
>  property does apply references that property via a
from-parent()
>  or from-nearest-specified-value() function call,
what value 
>  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
the property,
>and I'm not sure if a property has a computed value
if that 
>property doesn't apply (but I'm not sure if it
doesn't either,
>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 [1]:

"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."

[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#speccomact

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!

Thanks,
Glen


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Received on Friday, 16 January 2004 19:22:44 UTC