Comments on 2nd WD (part 8)

Editors:

More comments on the XSL 1.1 2WD:

(Note 71 & 72 are somewhat weaker suggestions--I sense
they would be good ideas, but am not certain of all
possible drawbacks.)

71.)  Section 6.13.4, fo:wrapper -- Consider switching
fo:wrapper's content model from
(#PCDATA|%inline;|%block;)* to (%inline;|%block;)+.

Reasons:
a.)  (for removing #PCDATA) fo:wrapper is a formatting
object that allows its properties to be inherited by
its descendant formatting objects. Parsed character
data is not a formatting object, but if we allow it to
be immediately descendant from fo:wrapper, then
fo:wrapper ends up being synonymous as an fo:block
(their CM's are currently the same, and both allow for
inheritance to occur).  If there is #PCDATA that the
stylesheet writer needs to have displayed, the
fo:block formatting object can perfectly handle it,
inheritance and all, possibly eliminating the need for
an fo:wrapper.

b.)  (for requiring at least one child node)--an
fo:wrapper is nonsensical without child items (i.e.,
perhaps we should require a descendant item just as we
require fo:list-block, for example, to have at least
one fo:list-item.)


72.) Section 6.13.4, fo:wrapper, and
fo:page-sequence-wrapper -- Similar to what was done
for fo:multi-sets and fo:initial-property-set in XSL
1.1, I would consider removing the ID property from
these two formatting objects.

Reasons:
a.)  This suggestion goes back again to the basics of
what the wrapper methods are for:  just convenience
FO's for inheriting property values during FO tree
building. These two FO's would seem to be ones that
should "dissolve" during FO Tree building and property
resolution, and not normally be the target within the
area tree.

b.)  Placing ID's on these two FO's are resulting in
needing to add somewhat convoluted ID processing rules
for both fo:page-sequence-wrapper[1] and fo:wrapper[2]
-- namely, for how to handle the IDs in cases where
the descendants generate no areas.  In particular, for
fo:wrapper:

"If the sequence of areas returned to the fo:wrapper
contains no normal areas, and the 'id' property is
specified on the fo:wrapper, then it additionally
generates and returns one normal area with
inline-progression-dimension and
block-progression-dimension set to zero."

These rules are a bit cumbersome both for the
Recommendation as well as for an implementation
handling it.  The inelegance here--needing to generate
an area because of the existence of the ID
property--is perhaps showing that the fo:wrapper
object is not really meant to the target of ref-id's.

[1]
http://www.w3.org/TR/xsl11/#fo_page-sequence-wrapper
[2] http://www.w3.org/TR/xsl11/#fo_wrapper


73.)  Section 6.13.4, fo:wrapper -- Recommend removing
the rule that allows an fo:wrapper to override its
parent FO's disallowing of fo:markers. I.e., to remove
the first exception from the fo:wrapper description:

"An fo:wrapper is only permitted to have children that
would be permitted to be children of the parent of the
fo:wrapper, with two exceptions:  1.)  An fo:wrapper
may always have a sequence of zero or more fo:markers
as its initial children."

Reason:  It does not appear that fo:wrapper should be
serving as a mechanism to circumvent the fo:wrapper's
parent's restrictions on fo:marker descendants--that
would be a side-effect outside the scope of this FO. 
If the fo:wrapper's parent FO does not allow markers,
there is probably a legitimate reason for it: either
it would nonsensical or not practical to implement for
the given FO.  (Further, if fo:markers *are*
needed/useful for the parent that doesn't allow them,
then the spec should probably be modified to allow the
parent to have a marker, without requiring an
fo:wrapper descendant.)


74.)  The content model for fo:layout-master-set
appears incorrect:

instead of: 
(simple-page-master|page-sequence-master|flow-map)+

I think something like this was intended:

((simple-page-master|page-sequence-master)+,(flow-map)*)


75.)  Section 6.2, Formatting Object Content --
Recommend to remove #PCDATA from the neutral container
listing as well as the  two out-of-line formatting
object listings following it (total of three places):

"The following formatting objects are "neutral"
containers and may be used, provided that the
additional constraints listed under each formatting
object are satisfied, anywhere where -->#PCDATA<--,
%block;, or %inline; are allowed:"

Reason:  For all FO's, except fo:bookmark-title, every
occurrence of #PCDATA in a content model is also
matched with a %block; and/or a %inline;, so no power
is gained by adding #PCDATA to this list.  However,
for fo:bookmark-title, whose CM is only (#PCDATA), the
list of FO's here:  multi-switch, multi-properties,
change-bar-begin, etc. is *not* relevant for it.


76.)  Section 6.6.15, fo:scaling-value-citation.  This
FO is missing an explanation of how the "cited
fo:external-graphic" is actually cited.

For example, for fo:page-number-citation, we have the
following definition of "cited page": "The cited page
is the page containing, as a descendant, the first
normal area returned by the formatting object with an
id trait matching the ref-id trait of the
fo:page-number-citation (the referenced formatting
object)."

I think we need a similar type of definition here for
"cited fo:external-graphic".


77.)  Section F, Changes from XSL 1.0/Miscellaneous
Changes:  Remove the "fo:page-index" formatting
object, as there is no FO with that name.  (The
indexing FO's may not need to be listed here either,
as they weren't present in XSL 1.0 anyway.)


78.)  Section 6.3, Formatting Object Summary, and
6.6.14  "folio-suffix" Common Usage definition --
"within" is misspelled:

The fo:folio-suffix formatting object specifies a
static suffix for the folio numbers -->witin<-- a
page-sequence.


79.)  Section 6.4.1, Introduction, first paragraph. 
Probably should add the fo:bookmark-tree to the
following sentence:

"The children of the fo:root formatting object are a
single fo:layout-master-set, an optional
fo:declarations, and a sequence of one or more
fo:page-sequences and/or fo:page-sequence-wrapper
elements."


80.)  Section 6.4.1, Introduction, second paragraph. 
Probably should add a sentence to this paragraph
indicating that fo:flow-map objects are now also
children of the fo:layout-master-set

"The children of the fo:layout-master-set are the
pagination and layout specifications." [paragraph
continues...]


Thanks,
Glen Mazza
Apache FOP Team

Received on Tuesday, 25 January 2005 01:12:31 UTC