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 

addition links for wd-xsl

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

from-page-master-region()

The editors,

Section 5.10.4 Property Value Functions, of Extensible Stylesheet
Language (XSL) Version 1.1, W3C Working Draft 16 December 2004, contains:

<quote>
object from-page-master-region(NCName?)

The from-page-master-region function returns the computed value of the
property whose name matches the argument specified, or if omitted for
the property for which the expression is being evaluated.

In XSL 1.1 this function may only be used as the value of the
"writing-mode" and "reference-orientation" properties. In addition the
argument of the function must be omitted. If an argument is present, it
is an error.

The computed value of the designated property is taken from that
property on the layout formatting object being used to generate the
region viewport/reference area pair.

If this function is used in an expression on a formatting object, F,
that is a descendant of an fo:page-sequence, then the computed value is
taken from the region specification that was used to generate the
nearest ancestor region reference area which has as its descendants the
areas returned by F.

If the argument specifies a property of a compound datatype and if the
expression only consists of the inherited-property-value function with
an argument matching the property being computed, it is interpreted as
an expansion with each component of the compound property having a value
of inherited-property-value with an argument matching the component. It
is an error if arguments matching a property of a compound datatype are
used in any other way.
</quote>

This, incidentally to my comments, should probably read:
<text>
object from-page-master-region()

The from-page-master-region function returns the computed value of the
property for which the expression is being evaluated.

In XSL 1.1 this function may only be used as the value of the
"writing-mode" and "reference-orientation" properties. Note that it is
an error if an argument is provided to this function.

The computed value of the target property is the computed value of that
property on the layout formatting object being used to generate the
region viewport/reference area pair.

If this function is used in an expression on a formatting object, F,
that is a descendant of an fo:page-sequence, then the computed value is
taken from the region specification that was used to generate the
nearest ancestor region reference area which has as its descendants the
areas returned by F.
</text>

The existing version of this text, in particular, draws attention to two
aspects of this definition. Firstly, it has a very restricted
application. Secondly, while it is based on other property value
functions, it's form is distinctly different from its companion
functions.  In other words, it feels like a kludge.

The restrictions of "lexical" inheritance in XSL-FO have been discussed
over a period of years, motivated by the need for some form of
inheritance from the page-masters.  Although I have not thought this
through, I offer the following suggestions in the hope that they may
stimulate discussion.

The two properties involved take effect on reference-areas. In Appendix
C.3 Property Table: Part II, under "Trait mapping", both have "See
prose", i.e. they participate in the definition of other traits.  Traits
apply only to areas.  Many are derived directly from FO properties;
others, like "writing-mode" and "reference-orientation" take effect only
in the development of traits on areas.  Might it be possible to provide
for direct inheritance of traits?

There exists already a model for "dynamic" inheritance, i.e.,
fo:marker/fo:retrieve-marker, and the newly proposed
fo:retrieve-table-marker.  It has been the cause of a great deal of
anguish, for me and other FOP developers at least, but most XSL
developers have found a solution to the problem.  What if a subset of
traits were defined to inherit directly from properties on their area's
controlling simple-page-master?  This set would not be extensive, so the
inheritance tree would not be particularly cpu or memory intensive.

This would entail either a) a change to the manner of inheriting
existing properties, or b) the definition of new properties whose
inheritance and usage characteristics are so defined.  Method b) brings
with it the necessity to arbitrate between. e.g., the existing
"writing-mode" and the new, say, "area-writing-mode".  I lean to using
a) in association with a switch that determines whether the old or new
mode is in effect.  The switch would default to 1.0 behaviour,
preserving the layout of existing fo: stylesheets.  It seems to me that
such a switch could be specified in fo:declarations.

Peter B. West
Project Defoe <http://defoe.sourceforge.net/>

reference-orientation

The editors,

I am seeking clarification of the semantics of reference-orientation. 
The Draft Recommendation has:
<quote>
7.20.3 "reference-orientation"

XSL Definition:
Value: 	0 | 90 | 180 | 270 | -90 | -180 | -270 | inherit
Initial: 	0
Inherited: 	yes (see prose)
</quote>

I don't find that the prose of 7.20.3 clarifies the semantics.  There is 
no further mention of inheritance in that text.  It does have:
<quote>
The "reference-orientation" property is applied only on formatting 
objects that establish a reference-area. Each value of 
"reference-orientation" sets the absolute direction for "top", "left", 
"bottom", and "right"; which is used by "writing-mode", "direction", and 
all positioning operations that are referenced to the reference-area or 
are nested within it.
</quote>

This is the only thing I can see that has any aspect of inheritance 
about it.

Assuming that a reference-orientation of 90 has been applied on the 
nearest ancestor reference area A of some reference area B, and is never 
re-specified, does this mean that the effective reference-orientation of 
B is 180?  If so, say that B has a reference-area descendant C, and that 
C has a reference-area descendant D, and that reference-orientation is 
never re-specified in the FO tree path to D. The implication is that the 
effective reference-orientation of C is 270, and that of D is 0.  In 
other words, does the "inheritance" of a single non-zero 
reference-orientation have the effect of causing multi-generation 
descendant reference-areas to "spin"?

If not, would the addition of 'reference-orientation="inherit"' on B, C 
and D cause them to "spin"?

"Spinning" seems to be a consequence of the way the Rec is currently 
worded.  I don't know whether any implementations displays this behaviour.

It would seem to me desirable to have the semantics defined along the 
following lines.

     Value:     0 | 90 | 180 | 270 | -90 | -180 | -270 | inherit
     Initial:   0
     Inherited: No

I.e. allow the "inherit" keyword, but deny default inheritance. The 
default value for all reference-areas is the initial value, 0. (Note 
that this behaviour is spelled out for the reference-area in a number of 
viewport/reference-area pairs.) "inherit" would, in the case above, 
cause "spinning", and this should be pointed out in explanatory text for 
the "inherit" value.

The description of the "integer" values is unchanged.

The problem arises, I think, because the trait "reference-orientation" 
is an accumulator, unlike other traits.

Peter West

Comments on 2nd WD (part 6)

Editors:

Correction on previous comment [1]:

45.) fo:bookmark-tree, *not* fo:bookmark-title, is what was intended.

[1] http://lists.w3.org/Archives/Public/xsl-editors/2005JanMar/0002.html

More comments on the XSL 1.1 2WD:

51.)  Section 7.22.10 Property starting-state [2], The initial value of
"show" for this property should be switched to "hide" instead, for reasons
relating to the two FO's--fo:bookmark and fo:multi-case--that this property
applies to:

a.)  For fo:bookmark, an initial value of "show", would mean that, upon
opening the document, all the bookmarks and subbookmarks below them should
be completely expanded by default.  That is non-standard, normally, for a
(say) 20-chapter book, you would have a list of bookmarks 1,2,3,4,...,20 in
unexpanded state, for each chapter.  To see bookmark sub-levels, the user
would click on a particular chapter desired.  (The PDF specification [3]
would be a good example of this usual behavior.)  Having a default of "show"
would require the stylesheet author to manually include
starting-state="hide" for each of the 20 top-level fo:bookmarks, in order to
get this usual behavior.

b.)  For fo:multi-case, its two main rules are as follows:

1.) The parent fo:multi-switch shall choose the first fo:multi-case child
where the property "starting-state" has the value equal to "show".

But with an initial value of "show", any fo:multi-case without an explicit
specification will always have an computed value of "show", so the
explicitly specified one might end up getting ignored.

2.) If no fo:multi-case has "starting-state" property value of "show", the
contents of no fo:multi-case should be displayed.

The only way this behavior could obtained with a initial value of "show"
would be to manually specify "hide" on every fo:multi-case, which would be
burdensome for the stylesheet author.

[2] http://www.w3.org/TR/xsl11/#starting-state
[3] http://partners.adobe.com/public/developer/pdf/index_reference.html

52.)  Section 5.1.1, Specified Values, last paragraph, recommend changing
from:

"Since it has no parent, the root of the result tree cannot use values
from -->its<-- parent formatting object; -->in<-- this case, -->the initial
value is used if<-- necessary."

to:

Since it has no parent, the root of the result tree cannot use values
from -->a<-- parent formatting object; -->for<-- this case, -->initial
values are used where<-- necessary.

53.)  Section 5.2, Shorthand Expansion, first Note.  Move the word "only" as
follows:

"Shorthands are -->only<-- included in the highest XSL conformance level:
"complete" (see 8 Conformance)."

"Shorthands are included -->only<-- in the highest XSL conformance level:
"complete" (see 8 Conformance)."

54.)  Section 5.3.1, Border and Padding Properties, 2nd paragraph.
Recommend switching from:

"If the corresponding relative property is specified on the formatting
object -->and<-- the absolute property -->only<-- specified by the expansion
of a shorthand, then the computed value of the absolute property is set to
the computed value of the corresponding relative property."

to

"If the corresponding relative property is specified on the formatting
object -->but<-- the absolute property specified -->only<-- by the expansion
of a shorthand, then the computed value of the absolute property is set to
the computed value of the corresponding relative property."

55.)  Section 5.3.1, 3rd paragraph.  Recommend switching from:

"The initial value -->must be<-- the same for all possible corresponding
properties."

to

"The initial value -->is<-- the same for all possible corresponding
properties."

(It is the Recommendation that does the defining of the initial values, so
"is" appears more appropriate here.)

56.)  Section 5.3.1, 4th paragraph.  Recommend switching from:

"The -->(corresponding)<-- properties that use the above rule to determine
their computed value are:"

to

"The -->corresponding relative<-- properties that use the above rule to
determine their computed value are:"

57.)  Section 5.5.4, Absolute-position Property, and 5.5.5 Relative-position
Property.  (2 places)  Recommend rewriting to remove the mathematical equals
symbol ("If absolute-position = 'absolute'...", "If relative-position =
'relative'...") from these two paragraphs, as we're in regular text here and
not a mathematical formula.

58.)  Section 5.8, Unicode BIDI Processing, third paragraph.  Explicit is
misspelled in the below sentence:

"The formatting object makes -->explict<-- the previously implicit right to
left positioning of the Arabic characters."

59.)  Section 5.8, Unicode BIDI Processing, last paragraph of item 2-b of
the list of constraints for inserting new fo:bidi-override objects.
Recommend switching from:

"Note that the fo:inline with -->id equal 'A'<-- has been split into two
fo:inlines with--> the first one having the original<-- id of 'A'."

to

"Note that the fo:inline with -->id equal to 'A'<-- has been split into two
fo:inlines-->, with only the first one retaining<-- the original id of 'A'."

60.)  Section 5.9.1, Property Context.  In the Note, switch the below "is"
to "be":

"It is not necessary that a conversion -->is<-- provided for all types. If
no conversion is specified, it is an error."

Thanks,
Glen Mazza
Apache FOP Team

Re: Comments on 2nd WD (part 6)

>
> 60.)  Section 5.9.1, Property Context.  In the Note, switch the below "is"
> to "be":
>
> "It is not necessary that a conversion -->is<-- provided for all types. If
> no conversion is specified, it is an error."
>

Actually, the two sentences of this Note appear to contradict themselves.
Perhaps this is what was intended:

"Conversions are not necessarily provided for all types.  If a needed
conversion is not available, it is an error."

Glen

5.3.2 Margin, Space, and Indent Properties

The editors,

I am seeking clarification of the last part of the discussion in 5.3.2.

It reads:

<quote>
If the corresponding absolute margin property is not explicitly 
specified, or if the corresponding relative property is specified on the 
formatting object and the absolute property only specified by the 
expansion of a shorthand, the corresponding absolute margin property is 
calculated according to the following formulae:

margin-corresponding = start-indent - inherited_value_of(start-indent) - 
padding-corresponding - border-corresponding-width

margin-corresponding = end-indent - inherited_value_of(end-indent) - 
padding-corresponding - border-corresponding-width

Note:

If the "start-indent" or "end-indent" properties are not specified their 
inherited value is used in these formulae.
</quote>

Looking at the case where neither the corresponding absolute margin 
property nor the corresponding relative property is explicitly 
specified, this becomes (for start):

margin-corresponding = inherited_value_of(start-indent) - 
inherited_value_of(start-indent) - padding-corresponding - 
border-corresponding

If (padding-corresponding + border-corresponding) > 0, we are left with 
a negative margin-corresponding.

If my understanding of these properties is correct, the problem could be 
eliminated as follows.

Change the current wording to:

'If the corresponding relative property is specified on the formatting 
object, and the formatting object does not generate a reference area, 
and the corresponding absolute margin property is not explicitly 
specified, or is only specified by the expansion of a shorthand, the 
corresponding absolute margin property is calculated according to the 
following formulae:'

The formulae are unchanged, but the offending Note is deleted.  Two 
additional conditions are added, along the following lines.

'If the corresponding relative property is specified on the formatting 
object, and the formatting object generates a reference area, and the 
corresponding absolute margin property is not explicitly specified, or 
is only specified by the expansion of a shorthand, the corresponding 
absolute margin property is calculated according to the following formulae:

margin-corresponding = start-indent - padding-corresponding - 
border-corresponding-width

margin-corresponding = end-indent - padding-corresponding - 
border-corresponding-width

If neither the corresponding relative property nor the corresponding 
absolute absolute margin property is specified on the formatting object, 
the corresponding relative property is inherited, and the corresponding 
absolute margin property is calculated according to the following formulae:

margin-corresponding = inherited_value_of(start-indent) - 
padding-corresponding - border-corresponding-width

margin-corresponding = inherited_value_of(end-indent) - 
padding-corresponding - border-corresponding-width'

Peter B. West

Typo in 7.7.9 "border-before-width"

I believe this is a typo:

"If border-before-width is specified using <length>, the formatter shall 
convert the single value to components as follows:
   ...
  o border-before-width.--->conditional<---: discard.

Should be "conditionality".

Cheers,

E.
--

-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122

ekimber <at> innodata-isogen.com
www.innodata-isogen.com

CFP - 2005 IEEE/WIC/ACM International Conference on Web Intelligence (WI'05)