Comments on 2nd WD (part 5)

Editors:

More comments on the XSL 1.1 2WD:

41.)  Section 4.3.1 - Space Resolution Rules, the
second paragraph after item #4.   Recommend rewriting
the sentence:

"The padding of a block-area does not interact with
any space-specifier --->(except that by definition,<--
the presence of padding at the before- or after-edge
prevents areas on either side of it from having a
stacking constraint.-->)"<--

to:

"The padding of a block-area does not interact with
any space-specifier. -->Note, however, that by
definition<---,  the presence of padding at the
before- or after-edge prevents areas on either side of
it from having a stacking constraint-->with respect to
each other.<--"

(Putting the "except" portion within parentheses is
somewhat non-standard, because usually parenthesized
expressions should just provide additional information
without modifying the meaning of the non-parenthesized
portion.)


42.)  Section 4.4, Block Areas - 1st paragraph. 
Recommend rewriting the sentence:

"All areas have these traits, but they -->only<-- have
relevance for areas -->which<-- have stacked line-area
children."

to

"All areas have these traits, but they have relevance
-->only<-- for areas -->that*<-- have stacked
line-area children."

(*The Microsoft Word grammar checker prefers "that"
for restrictive clauses, but dictionaries state that
"which" is still acceptable.  So I will mention this
point further only where it appears the
restrictiveness needs to be emphasized very strongly.)


43.)  Section 4.4, 3rd paragraph.  The -->it<-- needs
to be removed, I think the -->which is not a
line-area<-- perhaps should also be removed
(line-areas must also be properly stacked, correct?).

"A block-area -->which is not a line-area<-- must be
properly stacked (as defined in 4.4.1 Stacked
Block-areas below) unless otherwise specified in the
description of its generating formatting object. In
this case -->it<-- its block-progression-dimension
will be subject to constraints based on the
block-progression-dimensions and space-specifiers of
its descendants."


44.)  Section 4.4.2, 2nd paragraph.  Remove the
-->,<-- (commas should not be used with restrictive
clauses[1])

"If A and B are areas which have the same nearest
reference area ancestor, then A and B are defined to
be inline-overlapping if there is some line parallel
to the inline-progression-direction-->,<-- which
intersects both the allocation-rectangle of A and the
allocation-rectangle of B."

[1]
http://www.ucalgary.ca/UofC/eduweb/grammar/course/punctuation/3_4c.htm


45.)  Section 6.3, Formatting Objects Summary for
fo:bookmark-title *and* Section 6.11.1,
fo:bookmark-title. An "a" is omitted and "within" has
a typo in both places:

The fo:bookmark-tree formatting object is used to hold
--><-- list of access points -->withing<-- the
document such as a table of contents, a list of
figures or tables, etc.


46.)  Section 6.11.2, fo:bookmark:  The content model
for the fo:bookmark is incorrect.  It should be
(bookmark-title,bookmark*) and not
(bookmark-title,bookmark+).


47.)  Section 6.11.2, fo:bookmark:  The Note statement
"The fo:bookmark is a specialized form of the
fo:basic-link with restrictions on the applicable
properties and on its content model." seems
unnecessary, and the two FO's appear sufficiently
different that this statement should be removed, for
these reasons:

1.)  These two FOs' content models are quite
different, (fo:basic-link's is
(#PCDATA|%inline;|%block;)*) so fo:bookmark's CM
cannot be thought of as fo:basic-link's with
restrictions.

2.) fo:bookmark has a starting-state property that is
not applicable to fo:basic-link, so its applicable
properties are not just a subset of fo:basic-link.

3.)  Stating that fo:bookmark *is* a specialized form
of fo:basic-link tends to falsely imply that you can
use a fo:bookmark wherever you can use an
fo:basic-link.  Rather, "The fo:bookmark *can be
thought of* as a specialized form..." would be a
better phrasing but I still don't see the need for
this Note.


48.)  Section 6.11.3, fo:bookmark-title, likewise as
in #47 above, I'm unsure of the need/accuracy of
declaring fo:bookmark-title "to be a specialized form"
of fo:inline.  After all, fo:title can also be
considered to be a specialized form of fo:inline, but
fo:title does not have such a Note.  The Editors may
be opening up a can of worms by declaring FO's to be
specialized versions of each other--declarations that
aren't of much practical significance anyway.


49.)  Section 6.11.3, fo:bookmark-title, the two
statements listed in the Constraints section appear to
be duplicated from fo:bookmark, and are not relevant
for this FO.


50.)  Section 7.16.4 "text-decoration", for the Note
at the bottom, there is a spelling typo:

"Implementers [should be Implementors] should not make
any assumptions about how underlines are placed in
particular languages and should properly research the
languages that they wish to support."


Thanks,
Glen Mazza
Apache FOP Team