Comments on 2nd WD (part 4)

Editors:

More suggestions for the XSL 1.1 2WD:

31.)  Section 6.11.2 fo:bookmark [1] and 6.11.3 fo:bookmark-title are 
both declared to have the common accessibility properties applicable for 
them.  However, the description of both common accessibility properties 
[2] states that they are applicable only for FO's that are valid within 
fo:flow and fo:static-content.  (E.g., fo:root, fo:flow, and 
fo:static-content do *not* have these properties applicable for them.)  
But fo:bookmark-tree and its children are outside fo:flow and 
fo:static-content.  So there is an inconsistency here that can be fixed 
by either revisiting the need for fo:bookmarks to support CAP, or by 
removing the limitations stated in [2].

[1] http://www.w3.org/TR/xsl11/#fo_bookmark
[2] http://www.w3.org/TR/xsl11/#common-accessibility-properties


32.)  Section 7.4.1, "Source Document" property description [2] states:

"W3C Accessibility guidelines, http://www.w3.org/TR/WCAG20/, 
http://www.w3.org/TR/ATAG10/, and http://www.w3.org/TR/UAAG10/, strongly 
encourage the use of this property -->either on the fo:root or<-- on the 
first formatting object generated from a given source document."

However, the definition of fo:root [3] does not declare the 
source-document property to be applicable to it.  So there is an 
inconsistency here that can be fixed by modifying fo:root's applicable 
properties or by modifying the above sentence to remove the "--><--"'ed 
portion.  Note: a search on the three guidelines is giving no reference 
to a "root" or an "fo:root", so the latter option may be preferable.

[3] http://www.w3.org/TR/xsl11/#fo_root


33.) Section 6.11.2 fo:bookmark:  The new fo:bookmark has three other 
properties defined for it:  external-destination [4], 
internal-destination [5], and starting-state.[6]  The definitions for 
these properties need to be updated however because they carry over from 
1.0 and each hardcode the specific behavior of the then-only FO that 
used that property.  (For [4] and [5], fo:basic-link, and [6] 
fo:multi-case.)

It would probably be best to remove fo-specific references from these 
three property definitions, and then state something similar to "see the 
FO for additional FO-specific behavior of this property."  (Another 
option would be to add the bookmark-specific behavior with respect to 
these properties to the property definitions.  Currently, we're doing 
both, for example, for starting-state, fo:multi-case's specific behavior 
with respect to this property is "hardcoded" within the property 
definition but fo:bookmark's is defined within the FO.)

[4] http://www.w3.org/TR/xsl11/#external-destination
[5] http://www.w3.org/TR/xsl11/#internal-destination
[6] http://www.w3.org/TR/xsl11/#starting-state


34.)  Section 6.11.3 fo:bookmark-title [7]:  You may wish to consider 
removing the value space limitations placed on the font-style and 
font-weight properties, leaving it up to the XSL implementations of how 
they wish to handle unsupported or unavailable fonts-styles and/or 
font-weights, as they have to do already for fonts within regular text.

Reasons:
1.  The original reason for these limitations may have had to do with 
PDF bookmark limitations.  But the limitations of one render-target of 
course should not spill over to other render-targets as well.  (With 
that logic, the fact that some render-targets might not support 
bookmarks at all would then suggest us doing away with fo:bookmark-tree 
et. al. entirely.)

2.  It seems to set a precedent--limiting the range of a property for a 
particular FO--that is not really necessary.  XSL implementors already 
need to design fallbacks for unsupported font-weights and font-styles in 
regular text usage of the font.  (Fallbacks which are indeed already 
discussed in these property definitions.)  Creating fallbacks for 
fo:bookmark-title would be no more complex to implement, probably just 
reusing the same logic as used for text.

3.  The restrictions are of limited utility and make this FO less 
consistent with others.  Disallowing an explicit declaration of 
"inherit" is strange/nonstandard, given that inheritance is allowed for 
these properties.  Also, the font-style property definition allows for 
an oblique font to be the backup for an italic font, so explicitly 
prohibiting an oblique font is of questionable value.  Font weights are 
frequently limited to normal/bold anyway, and methods for 
handling/resolving unavailable font weights are already discussed with 
the font-weight property.

[7] http://www.w3.org/TR/xsl11/#fo_bookmark-title


35.)  Section 4.1, Paragraph 7 ("The semantics of each type...")  Add 
"to be" in the two indicated places below in the following sentence:

"The properties of the formatting object determine what areas are -->to 
be<-- generated and how the formatting object's content is -->to be<-- 
distributed among them. (For example, a word that is not to be 
hyphenated may not have its glyphs distributed into areas on two 
separate line-areas.)"

(This places the sentence more clearly in the future tense, and also 
follows the grammar used in the subsequent parenthesized sentence.)


36.)  Section 4.1, Paragraph 10:  (the definition of 
"indirectly-derived")  Add "also" in the indicated place below:

"The calculation formula may -->also<-- depend on the type of the 
formatting object."


37.)  Section 4.2.2 Common Traits, Paragraph 3.  ("The Boolean trait 
is-reference-area...") Recommend removing the last sentence:

"A reference-area may be either a block-area or an inline-area."

and replacing it with something similar to:

"See Section 5.6 for the list of formatting objects that generate 
reference-areas."

Such a switch would greatly help in immediately clarifying to the novice 
reader which areas are reference-areas and which are not.  Also, it 
further clarifies that this trait is specifically *defined* for certain 
FO's and their areas, and not a variable trait that can apply to 
any/most areas generated by any/most FO's.  (The former sentence tends 
to give that impression, causing confusion.)


38.)  Section 4.2.3 Common Traits, Paragraph 9  (first bulleted item, 
"the is-first and is-last traits...")  Remove the nested parentheses, 
perhaps as follows:

From:

"(See 6.1.1 Definitions Common to Many Formatting Objects. is-first is 
true for the first area (or only area) generated and returned by a 
formatting object, and is-last is true for the last area (or only area));"

To:

"(See 6.1.1 Definitions Common to Many Formatting Objects.) is-first is 
true for the first area (or only area) generated and returned by a 
formatting object, and is-last is true for the last area (or only area);"


39.)  Section 4.2.5, Stacking Constraints, first paragraph.  Add "may" 
where indicated below:

"The intention of the definitions is to identify areas at any level of 
the tree which -->may<-- have only space between them."

(Areas that do not have stacking constraints can also just have space 
between them.  Here, we are trying to identify areas that may *only* 
have space between them.  This change would also make the statement 
consistent with the one earlier in the paragraph which says these 
constraints are ordered relations.  I.e., if the only purpose of the 
constraint definitions were to identify areas that just happen to have 
only space between them, than the constraints would *not* be ordered, 
e.g., if A&B had a stacking constraint, then B&A would as well.)


40.)  Section 4.3, Spaces and Conditionality, 4th paragraph.  It would 
be good to add a basic definition of the "precedence" component of the 
space-specifier datatype here, just as the preceding paragraphs already 
give pretty good semantic definitions of the other four components of 
this datatype.


Thanks,
Glen Mazza
Apache FOP Team

Received on Saturday, 1 January 2005 19:18:36 UTC