W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2004

Re: XSL 1.1 WD comment: The properties which may be attached to an F O.

From: Paul Grosso <pgrosso@arbortext.com>
Date: Thu, 15 Jan 2004 09:37:54 -0600
Message-Id: <>
To: "Mazza, Glen R., ,CPMS" <glen.mazza@cpms.osd.mil>, "'xsl-editors@w3.org'" <xsl-editors@w3.org>

At 19:36 2004 01 14 -0500, Mazza, Glen R., ,CPMS wrote:

>Hello, I'm Glen Mazza of Electronic Data Systems and of the XML Apache FOP

Thanks for your input.  The XSL FO subgroup will be considering all
comments in the formulation of our next draft.

I've got some comments just from myself (not the group) embedded below.

>I'm unsure, after reading the 1.1 Working Draft of the XSL Specification,
>about the set of properties which may be attached to an FO.  The
>Introduction and Overview, Section 1.1.2 Formatting [1], gives this
>"Although every formatting property may be specified on every formatting
>object, for each formatting object class, only a subset of the formatting
>properties are used to determine the traits for objects of that class."
>Section 5.1.4, Inheritance [2], gives this rule:
>"The inheritable properties can be placed on any formatting object."
>[1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#d0e178
>[2] http://www.w3.org/TR/2003/WD-xsl11-20031217/#inheritance
>Two comments on these statements:
>1.) 5.1.4's statement seems to contradict 1.1.2's by implying that
>noninheritable properties cannot be placed on every formatting object.  If
>1.1.2's statement is correct, however, it would be better for the reader if
>5.1.4's were written more unambiguously as: 
>The inheritable properties, like all properties, can be placed on any
>formatting object.

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)".  The reason it makes sense to put
an inheritable property on an FO to which it doesn't apply
is that such a property may be applicable to a descendant
FO which will inherit the value.

I don't find the statement in 5.1.4 particularly confusing.

The problem with your suggested clarification is that that
might be seen as implying that it somehow "makes sense" to
put non-inheritable properties everywhere, and it doesn't.

>2.) The rule given by 1.1.2--every property can be attached to every FO--is
>very significant for implementors, and should not be limited to just a
>subordinate clause of a sentence in the introduction.  Of course,
>introductions should not be the only place where a specification rule is

But the statement in 1.1.2 is so basic to understanding the entire
model that it makes perfect sense to put it in the introduction.

I see no reason that introductions can't be the only place something
is said.  The introduction is equally normative to the rest of the
normative parts of the spec.  An implementor can't skip the introduction.

>Somewhere in the body of the specification this rule should be explicitly
>stated--absent such an statement, I'm not getting a "firm handshake" from
>the authors about this rule

Please consider statements in the introduction firm handshakes.

>--causing me to think that 5.1.4's current
>statement is what they were  intending.  

It is what we intend, but it does not contradict 1.1.2.  You are
reading things into the wording of 5.1.4 that aren't there.

Received on Thursday, 15 January 2004 10:46:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:23 UTC