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

Comments on 2nd WD (part 5)

From: Glen Mazza <grm7793@yahoo.com>
Date: Sat, 8 Jan 2005 12:58:03 -0800 (PST)
Message-ID: <20050108205803.99130.qmail@web80501.mail.yahoo.com>
To: xsl-editors@w3.org

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
Received on Saturday, 8 January 2005 20:58:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:58 GMT