Comments on 2nd WD (part 6)

Editors:


Correction on previous comment [1]:

45.) fo:bookmark-tree, *not* fo:bookmark-title, is what was intended.

[1] http://lists.w3.org/Archives/Public/xsl-editors/2005JanMar/0002.html


More comments on the XSL 1.1 2WD:

51.)  Section 7.22.10 Property starting-state [2], The initial value of
"show" for this property should be switched to "hide" instead, for reasons
relating to the two FO's--fo:bookmark and fo:multi-case--that this property
applies to:

a.)  For fo:bookmark, an initial value of "show", would mean that, upon
opening the document, all the bookmarks and subbookmarks below them should
be completely expanded by default.  That is non-standard, normally, for a
(say) 20-chapter book, you would have a list of bookmarks 1,2,3,4,...,20 in
unexpanded state, for each chapter.  To see bookmark sub-levels, the user
would click on a particular chapter desired.  (The PDF specification [3]
would be a good example of this usual behavior.)  Having a default of "show"
would require the stylesheet author to manually include
starting-state="hide" for each of the 20 top-level fo:bookmarks, in order to
get this usual behavior.

b.)  For fo:multi-case, its two main rules are as follows:

1.) The parent fo:multi-switch shall choose the first fo:multi-case child
where the property "starting-state" has the value equal to "show".

But with an initial value of "show", any fo:multi-case without an explicit
specification will always have an computed value of "show", so the
explicitly specified one might end up getting ignored.

2.) If no fo:multi-case has "starting-state" property value of "show", the
contents of no fo:multi-case should be displayed.

The only way this behavior could obtained with a initial value of "show"
would be to manually specify "hide" on every fo:multi-case, which would be
burdensome for the stylesheet author.

[2] http://www.w3.org/TR/xsl11/#starting-state
[3] http://partners.adobe.com/public/developer/pdf/index_reference.html


52.)  Section 5.1.1, Specified Values, last paragraph, recommend changing
from:

"Since it has no parent, the root of the result tree cannot use values
from -->its<-- parent formatting object; -->in<-- this case, -->the initial
value is used if<-- necessary."

to:

Since it has no parent, the root of the result tree cannot use values
from -->a<-- parent formatting object; -->for<-- this case, -->initial
values are used where<-- necessary.


53.)  Section 5.2, Shorthand Expansion, first Note.  Move the word "only" as
follows:

"Shorthands are -->only<-- included in the highest XSL conformance level:
"complete" (see 8 Conformance)."

"Shorthands are included -->only<-- in the highest XSL conformance level:
"complete" (see 8 Conformance)."


54.)  Section 5.3.1, Border and Padding Properties, 2nd paragraph.
Recommend switching from:

"If the corresponding relative property is specified on the formatting
object -->and<-- the absolute property -->only<-- specified by the expansion
of a shorthand, then the computed value of the absolute property is set to
the computed value of the corresponding relative property."

to

"If the corresponding relative property is specified on the formatting
object -->but<-- the absolute property specified -->only<-- by the expansion
of a shorthand, then the computed value of the absolute property is set to
the computed value of the corresponding relative property."


55.)  Section 5.3.1, 3rd paragraph.  Recommend switching from:

"The initial value -->must be<-- the same for all possible corresponding
properties."

to

"The initial value -->is<-- the same for all possible corresponding
properties."

(It is the Recommendation that does the defining of the initial values, so
"is" appears more appropriate here.)


56.)  Section 5.3.1, 4th paragraph.  Recommend switching from:

"The -->(corresponding)<-- properties that use the above rule to determine
their computed value are:"

to

"The -->corresponding relative<-- properties that use the above rule to
determine their computed value are:"


57.)  Section 5.5.4, Absolute-position Property, and 5.5.5 Relative-position
Property.  (2 places)  Recommend rewriting to remove the mathematical equals
symbol ("If absolute-position = 'absolute'...", "If relative-position =
'relative'...") from these two paragraphs, as we're in regular text here and
not a mathematical formula.


58.)  Section 5.8, Unicode BIDI Processing, third paragraph.  Explicit is
misspelled in the below sentence:

"The formatting object makes -->explict<-- the previously implicit right to
left positioning of the Arabic characters."


59.)  Section 5.8, Unicode BIDI Processing, last paragraph of item 2-b of
the list of constraints for inserting new fo:bidi-override objects.
Recommend switching from:

"Note that the fo:inline with -->id equal 'A'<-- has been split into two
fo:inlines with--> the first one having the original<-- id of 'A'."

to

"Note that the fo:inline with -->id equal to 'A'<-- has been split into two
fo:inlines-->, with only the first one retaining<-- the original id of 'A'."


60.)  Section 5.9.1, Property Context.  In the Note, switch the below "is"
to "be":

"It is not necessary that a conversion -->is<-- provided for all types. If
no conversion is specified, it is an error."


Thanks,
Glen Mazza
Apache FOP Team

Received on Saturday, 15 January 2005 16:42:10 UTC