Comments on 2nd WD (part 7)

Editors:

More comments on the XSL 1.1 2WD:

61.)  I would like the Editors to reconsider the current allowing of empty
fo:page-sequence-wrappers.  I.e., to switch the fo:page-sequence-wrappers's
content model from

(page-sequence|page-sequence-wrapper)*
to
(page-sequence|page-sequence-wrapper)+.

My concerns about empty page-sequence-wrappers are as follows:

a.)  Given fo:root's 1.1 content model, it would allow for a valid FO
document to contain no page-sequences at all.  In effect, it would be like
changing 1.0's fo:root's content model from

(layout-master-set,declarations?,page-sequence+)
to
(layout-master-set,declarations?,page-sequence*)

But an FO document without a page-sequence is nonsensical.  Without a
page-sequence, you do not have an FO document to process.

b.)  There is no reason to create a page-sequence-wrapper if there is no
underlying fo:page-sequence.   For proper design, we should require at least
one page-sequence for this FO, just like we already require at least one
flow for a page-sequence, at least one block-item for an fo:flow or
fo:inline-container, at least one bookmark for an bookmark-tree, etc.

c.)  It may cause the fo:page-sequence-wrapper to be misused.  Because one
can attach the property "id" to it, we may soon find usage of empty
page-sequence-wrappers to determine total page counts, page counts between
page-sequences, etc.  Usages of FO's outside its stated purpose (a
page-sequence-wrapper is just meant to be a holder for properties that are
to be inherited by its child page-sequences) will hurt the integrity of the
XSL standard.

d.)  The reason for allowing empty p-s-w may be to make creation of XSL
documents somewhat simpler--i.e., via SAX, DOM or XSLT programming, it may
be coding-wise a little simpler to create a p-s-w object without needing to
be concerned about the presence of a page-sequence.  But the complexity
savings is rather minimal (i.e., methods exist to refrain from creating a
p-s-w until the first page-sequence appears, just like users have always had
the ability to check for fo:flows before creating a page-sequence), so this
doesn't appear to justify weakening this FO's content model.

e.)  Content models are extremely helpful for users to understand proper XSL
document design, especially the relationships between the various FO's.  In
general, we would appear to be hurting comprehension of the XSL
recommendation if we decide to base the CM's not on what would make a
sensical document but on what would save a few lines of programmatic code
here and there.

f.)  Finally, the current CM's of fo:root and fo:page-sequence-wrapper, when
taken together, are sending an inconsistent message:  "It is now valid for
an FO document to have no fo:page-sequence, but you must have at least one
empty fo:page-sequence-wrapper."  But if it is valid for an FO document to
have no fo:page-sequences, then the presence or absence of empty
fo:page-sequence-wrappers should be of no consequence.  So if my suggestion
is not taken, I would then (unfortunately!) need to recommend switching
fo:root's 1.1 CM to remove the empty p-s-w requirement:

from:
(layout-master-set,declarations?,bookmark-tree?,(page-sequence|page-sequence
-wrapper)+).
to:
(layout-master-set,declarations?,bookmark-tree?,(page-sequence|page-sequence
-wrapper)*).

(But I would most certainly prefer the change to fo:p-s-w's CM instead!)


62.)  I'm not certain if this is a bug, but the content model for
fo:simple-page-master switched from 1.0 to 1.1 as follows:

1.0 -- (region-body,region-before?,region-after?,region-start?,region-end?)

1.1 -- (region-body+,region-before?,region-after?,region-start?,region-end?)

Is the 1.1 CM for this FO correct?  I.e., can we now have multiple
region-body objects for a simple-page-master?  I'm not seeing how this could
be of use, but I'm unsure.


63.)  Section 5.9.2, Evaluation Order, second paragraph.  Unless I'm
misreading the sentence, I think "properties" should be switched to
"property" below:

Once the "font-size" property has been evaluated, that value is used as the
current font-size for all property contexts of all -->properties<-- value
expressions being further evaluated.


64.)  Section 5.9.8, Strings, only paragraph.  It appears here also that
"properties" should be switched to "property", because the object referred
to in the singular is a "property context":

All -->properties<-- contexts allow conversion from enumeration tokens to
strings. See 5.9.12 Expression Value Conversions.


65.)  Section 5.9.13, Definitions of Units of Measure, Point #2, Bullet 4.
Recommend changing from:

"unreadable results including unacceptably small text/layout (for example, a
layout was -->done<-- at 72 dpi [dots per inch], but the renderer assumed
the result was already specified in device dots and -->renders<-- it at 600
dpi --><--)."

to:

"unreadable results including unacceptably small text/layout (for example, a
layout was -->calculated [or "performed"]<-- at 72 dpi [dots per inch], but
the renderer assumed the result was already specified in device dots
and -->rendered<-- it at 600 dpi -->instead<--)."


66.)  Section 5.10.1, Number Functions, first Note.  Add "also" where
indicated:

This -->also<-- applies to the ceiling, round, and other such functions
where a unit power of zero is required.


67.)  Section 5.10.2, Color Functions, function "color
system-color(NCName)".  Recommend switch from "a" to "the":

The system-color function returns a system defined color with [a-->the]
given name.


68.)  Section 5.10.4, Property Value Functions, first paragraph.  Recommend
switch from "inherited" to "inheritable":

It is an error if this property is not an [inherited-->inheritable]
property.


69.)  Section 5.10.4, Property Value Functions, second paragraph.  Recommend
switch from:

"In particular, given the following example:"
to:
"For example, given the following:"


70.)  Section 5.11 Property Datatypes, first Note.  Recommend removing two
commas and adding one as follows:

from:  "Since a <percentage> value-->,<-- that is not interpreted as
"auto"-->,<-- is a valid <length> value it may be used in a short form."

to: "Since a <percentage> value that is not interpreted as "auto" is a valid
<length> value-->,<-- it may be used in a short form."


Thanks,
Glen Mazza
Apache FOP Team

Received on Saturday, 22 January 2005 00:52:34 UTC