W3C

Disposition of Comments on XSL Candidate Recommendation

Comment 1 (XSL WG comment):

Message-ID: <017201c0481f$a570e800$26020001@vgi.com>
From: "Glenn Adams" <gadams@vgi.com>
To: "W3C XSL FO SG"
Date: Mon, 6 Nov 2000 13:30:31 -0500
Subject: table column groups

Item 1

The lack of an fo:table-column-group prevents one from specifying a border and a
background on a column group that would support the CSS2 transparency layer and
border collapse algorithms as well as the rendition of HTML4 tables the
"rules=groups" attribute.

Is this lack of functionality intentional?

Disposition: Accepted (editorial)

The "column group" backgrounds are handled using the background of fo:table-column with number-columns-spanned greater than 1. A note as been added pointing this out and the list of areas for background generated by the fo:table changed to include "spanned areas" (XSL term) rather than "column-groups" (CSS2 term). Borders are handled at the XSLT stage when constructing the FO tree.

Links to the changed text in the XSL recommendation:

See link to changed text.

Regards,
Glenn

Comment 2 (XSL WG comment):

Message-ID: <003801c051e3$d61e2620$47070001@vgi.com>
From: "Glenn Adams" <gadams@vgi.com>>
To: "W3C XSL FO SG"
Date: Sat, 18 Nov 2000 23:47:33 -0500
Subject: fo:character needs to generate multiple glyph areas!

Item 1

I am concerned that the descripiton of fo:character and the text in 4.9.5
overconstrains the character to glyph mapping process. In paricular, the text
described in the following has fo:character generating only *one* glyph area.
Were this constraint be enforced, then it would be impossible to correctly
render a variety of scripts where there are cases that a single character maps
two two distinct, non-contiguous glyphs. For example, the following vowel in
Malayalam maps to two glyphs which are placed on either side of the glyph
generated from the preceding consonant character.

U+0D4C MALAYALAM VOWEL SIGN AU

For example, if one has:

<fo:character character="&#x0D15"> <!-- MALAYALAM CONSONANT KA  -->
<fo:character character="&#x0D4C"> <!-- MALAYALAM VOWEL SIGN AU -->

Then, under default rendering of this script, this consonant (C) and vowel (V)
would generate three inline glyph areas G1 G2 G3. This works out to a
correspondence as follows:

C => G2
V => G1, G3

Note that for this script, there is no ligating among these three glyphs.

The XSL text which concerns me includes the following.

Under section 6.6.3, fo:character, there appears:

The fo:character flow object represents a character that is mapped to a glyph
for presentation ...
The fo:character formatting object generates and returns a single normal
inline-area.

Also under 4.9.5, Intrinsic Marks, there appears:

For example, an fo:character object generates a glyph-area ...

Discussion message:

Message-Id: <4.2.0.58.J.20001120134532.035d93c0@sh.w3.mag.keio.ac.jp>
Date: Mon, 20 Nov 2000 13:46:51 +0900
To: "Glenn Adams" <gadams@vgi.com>, "W3C XSL FO SG"
From: "Martin J. Duerst" <duerst@w3.org>
Subject: Re: fo:character needs to generate multiple glyph areas!

I fully agree with Glenn that this needs to be fixed.
But this should be done during CR, not before going to CR.
Maybe before going to CR, a note could be added that
there is some need for more work.


Regards,   Martin.

At 00/11/18 23:47 -0500, Glenn Adams wrote:
>I am concerned that the descripiton of fo:character and the text in 4.9.5
>overconstrains the character to glyph mapping process. In paricular, the text
>described in the following has fo:character generating only *one* glyph area.
>Were this constraint be enforced, then it would be impossible to correctly
>render a variety of scripts where there are cases that a single character maps
>two two distinct, non-contiguous glyphs. For example, the following vowel in
>Malayalam maps to two glyphs which are placed on either side of the glyph
>generated from the preceding consonant character.
>
>U+0D4C MALAYALAM VOWEL SIGN AU
>
>For example, if one has:
>
><fo:character character="&#x0D15"> <!-- MALAYALAM CONSONANT KA  -->
><fo:character character="&#x0D4C"> <!-- MALAYALAM VOWEL SIGN AU -->
>
>Then, under default rendering of this script, this consonant (C) and vowel (V)
>would generate three inline glyph areas G1 G2 G3. This works out to a
>correspondence as follows:
>
>C => G2
>V => G1, G3
>
>Note that for this script, there is no ligating among these three glyphs.
>
>The XSL text which concerns me includes the following.
>
>Under section 6.6.3, fo:character, there appears:
>
>The fo:character flow object represents a character that is mapped to a glyph
>for presentation ...
>The fo:character formatting object generates and returns a single normal
>inline-area.
>
>Also under 4.9.5, Intrinsic Marks, there appears:
>
>For example, an fo:character object generates a glyph-area ...

Discussion message:

Message-ID: <OF36C983DE.A7366200-ON8525699D.007811A0@pok.ibm.com>
From: "Anders Berglund" <alrb@us.ibm.com>
Date: Mon, 20 Nov 2000 16:52:59 -0500
Subject: Re: fo:character needs to generate multiple glyph areas!


I am not so sure that more than one glyph area should be
generated or if the actual display using GLYPHS IN THE FONT
(design and architecture dependent) is the place where one
"ideal glyph" (=XSL) is mapped into more for the distplay. I think
it is quite analogous to a case where the "ideal glyph" for
"A with ring" is displayed using a "font glyph" for "A" and
a "font glyph" for the "ring". In this case I think it is very
clear that XSL should see it as only ONE glyph.
In the Malayalan case cited I can see the display of "ideal glyph"s
CW being rendered as the sequence w1cw2 of "font glyphs"
(with an adjustment of the position of "c" to get appropriate spacing).

One way to decide on the model would be to see if the AFII
registry has one glyph or two glyphs to make up x0d4c.
(Glenn do you have the registry handy - mine is in RI and I am
im NY).

Anders

Discussion message:

Message-ID: <3A19A187.481FBB7B@bitstream.com>
Date: Mon, 20 Nov 2000 17:11:19 -0500
From: jcaruso@pageflexinc.com (Jeff Caruso)
To: Anders Berglund <alrb@us.ibm.com>
Subject: Re: fo:character needs to generate multiple glyph areas!

Anders Berglund wrote:

> I am not so sure that more than one glyph area should be
> generated or if the actual display using GLYPHS IN THE FONT
> (design and architecture dependent) is the place where one
> "ideal glyph" (=XSL) is mapped into more for the distplay. I think
> it is quite analogous to a case where the "ideal glyph" for
> "A with ring" is displayed using a "font glyph" for "A" and
> a "font glyph" for the "ring". In this case I think it is very
> clear that XSL should see it as only ONE glyph.
> In the Malayalan case cited I can see the display of "ideal glyph"s
> CW being rendered as the sequence w1cw2 of "font glyphs"
> (with an adjustment of the position of "c" to get appropriate spacing).
>
> One way to decide on the model would be to see if the AFII
> registry has one glyph or two glyphs to make up x0d4c.
> (Glenn do you have the registry handy - mine is in RI and I am
> im NY).

I think no further change is needed.

Section 4.6.2 (Glyph-areas) already makes it clear that a glyph-area can come
from more than one character:

       The most common inline-area is a glyph-area, which contains the
representation for a
       character (or characters) in a particular font.

The way this comes about is described in section 4.7.2 (Line-building), point
5:

               * S_i consists of inline-areas then B_i is a line-area whose
child areas are the same as
               the inline-areas in S_i, and in the same order, except that
where the rules of the
               language and script in effect call for glyph-areas to be
substituted, inserted, or
               deleted, then the substituted or inserted glyph-areas appear in
the area tree in the
               corresponding place, and the deleted glyph-areas do not appear
in the area tree.

This basically asserts that the order of the inline-areas is unchanged from the
fo tree to the area tree, except in these cases, which include the case that
Glenn was referring to when he began this thread.

Regards,
 -- JeffC

******************************************************
Dr. Jeffrey L. Caruso <jcaruso@pageflexinc.com>
Pageflex, Inc.  215 First St.  Cambridge, MA 02142
(A Bitstream company)

Discussion message:

Message-ID: <022d01c05341$cb713eb0$26020001@vgi.com>
From: "Glenn Adams" <gadams@vgi.com>
To: "Jeff Caruso" <jcaruso@pageflexinc.com>, "Anders Berglund" <alrb@us.ibm.com>
Date: Mon, 20 Nov 2000 17:32:41 -0500
Subject: Re: fo:character needs to generate multiple glyph areas!

My only comment to this would be:

* add reordered to substituted and deleted in the text you quote below
* fix the text that I referred to in my initial message (4.9.5 and 6.6.3) where
it says "*a* glyph area"

Discussion message:

Message-ID: <022301c05340$abc52410$26020001@vgi.com>
From: "Glenn Adams" <gadams@vgi.com>
To: "Anders Berglund" <alrb@us.ibm.com>
Date: Mon, 20 Nov 2000 17:24:38 -0500
Subject: Re: fo:character needs to generate multiple glyph areas!


It's actually more complicated than I suggested earlier. One of glyphs from the
multiple glyphs generated by a character may ligate with a glyph produced by a
different character. For example, in Unicode 3.0, pg 231, under ligature rule 2,
you will find 6 instances in Tamil where one of the glyphs (the one on the right
of the consonant) generated from a "precomposed vowel" ligates with the glyph
produced by the consonant character which precedes the precomposed vowel
character.

Disposition: Accepted (bug in spec)

Links to the changed text in the XSL recommendation:

See link to changed text.



Comment 3 (XSL WG comment): lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0084.html

Message-ID: <004a01c046b7$98aabe20$47070001@vgi.com>
From: "Glenn Adams" <gadams@vgi.com>
To: "XSL Editors" <xsl-editors@w3.org>
Date: Sat, 4 Nov 2000 18:31:39 -0500
Subject: Interpretation of left,right,top,bottom as used with CSS2 properties

Item 1

In many cases, CSS2 specifies that left and right are to be interpreted with
respect to the "direction" property, with left mapping to right and vice-versa
for right-to-left directionality. Does this interpretation also apply for those
CSS2 properties permitted in XSL?

Disposition: Explanation of XSL spec

The following are the places where CSS uses the value of "direction" to vary the behavior of a CSS construct:

1. For "compact" boxes, direction determines which margin the compact box is positioned within. (Not applicable to XSL)

2. For determination of the "containing block", Rule 4. If the element has 'position: absolute', the containing block is established by the nearest ancestor with a 'position' other than 'static', in the following way:

a. In the case that the ancestor is block-level, the containing block is formed by the padding edge [p. 82] of the ancestor.

b. In the case that the ancestor is inline-level, the containing block depends on the 'direction' property of the ancestor:

i. If the 'direction' is 'ltr', the top and left of the containing block are the top and left content edges of the first box generated by the ancestor, and the bottom and right are the bottom and right content edges of the last box of the ancestor.

ii. If the 'direction' is 'rtl', the top and right are the top and right edges of the first box generated by the ancestor, and the bottom and left are the bottom and left content edges of the last box of the ancestor. If there is no such ancestor, the content edge of the root element's box establishes the containing block.

In XSL these rules are handled by referring to the writing mode relative edges.

3. For 10.3.3 Block-level, non-replaced elements in normal flow, there is an equation that determines the unspecified values for margins, padding, borders and content width relative to the content width of the containing block:

'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' = width of containing block

If this equation is overconstrained, then the margin away from the start side of the containing block is relaxed to solve the constraint. Direction is used to determine the "start" side. This is handled in section 5.3.4 Overconstrained Geometry in the XSL spec.

4. For 10.3.7 Absolutely positioned, non-replaced elements and 10.3.8 Absolutely positioned, replaced elements, there is an equation similar to that in 3. above, but this new equation adds in 'left' and 'right' which are the offsets from the content edge of the containing block. These "offsets" are used to position the absolutely positioned block and may take the value 'auto'. There are two different direction based rules for handling 'left' and 'right'.

The first of these rules covers the case where 'left' (or 'right') is the start-edge and its value is "auto". In this case, 'left' (correspondingly 'right') is set to an amount that would put the starting margin edge where the starting margin edge of the first "box" of the content of the containing block would have been placed. It is not totally clear which cases this is supposed to cover, but experiments with the existing browsers indicate that setting 'text-indent' will change where the first (inline) box is placed in a block and, therefore, the absolutely positioned block has its starting margin edge aligned to that of the first (inline) box. This works whether the indent is into the block or back outside the block.

The second rule is a variant of the rule in 3. above, but instead of relaxing the margin value on the end edge, it relaxes the 'right' (or 'left') value that corresponds to the end edge of the containing block.

5. For Left and Right pages (13.2.4), the direction (and writing mode) will influence whether the first page is a left or right page. This is not a concern for XSL because we do not right or left pages, but instead use even or odd pages.

6. For 16.2 Alignment: the 'text-align' property, the initial value depends on direction. This is not a problem in XSL because we can describe the dependence by setting the initial value to 'start'.

7. For 17.5 Visual layout of table contents, direction controls on which side of the table the first column is placed and how cell spans are placed. This use of direction is explicitly covered by Writing-mode for XSL.

8. For 17.5.4 Horizontal alignment in a column, "Character directionality determines whether the string lies to the left or right of the axis" when aligning to a string, such as the decimal point, in the content of a column. This is really an observation.

Item 2

                                  Furthermore, does this extend to variable
interpretations of top/bottom w.r.t. block-progression-direction?

Disposition: Explanation of XSL spec

Yes, but the XSL text does that automatically being expressed in terms of start and end edges which work for all writing-modes.

Item 3

                                                                  Finally, does
this intepretation also apply to absolute position properties left, right, top,
bottom?

Disposition: Explanation of XSL spec

This is a bit hard to answer. The cases above show that there are places where the absolute position properties behavior is influenced by direction. But, there is, in general, no relabeling of the absolute properties due to direction. See above for the details.

Regards,
Glenn

Comment 4 (public comment): lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0137.html

Message-ID: <002301c04e16$57aa27b0$0a01a8c0@grig>
From: "Nikolai Grigoriev" <grig@renderx.com>
To: <xsl-editors@w3.org>
Date: Tue, 14 Nov 2000 11:37:58 +0300
Subject: Column areas and span="all"

Dear XSL Editors,

Item 1

while implementing multi-column layouts, we have encountered problems in  spec
interpretation.

Consider this case:

<fo:block>
  <fo:block span="all">SPANNED</fo:block>
<fo:block>

The outer block has an implicit value of span="none". Therefore, by definition
of the "span" property [WD 7.18.5], "this object does not span multiple
columns". It looks like having children with span="all" is illegal in this case.

If we swap the location of attributes, we still get interpretation problems:

<fo:block span="all">
  <fo:block>SOME TEXT</fo:block>
<fo:block>

The outer block "shall span all the columns of a multi-column region", and the
inner one "does not span multiple columns" (because @span is not inheritable,
with the initial value of "none"!). Therefore, for a layout to be consistent,
one should never nest blocks with different values of span="all".

This turned out to be extremely unpractical. When designing a stylesheet, you
have to care about every block-level element if it will be placed into a spanned
region, or into a normal one; you need either to switch modes, or to keep an
extra parameter just to pass the @span value down to all block-level descendants
of a spanned  block. (Using "inherited" of "from-parent()" value does not help
much - you should care to specify this on every wrapper inside your block, but
not outside. And "from-nearest-specified-value()" risks to destroy
floats/footnotes).

My suggestion is to get rid of all these. If a flow-region should be subdivided
into span-reference-areas, let us design a special formatting object to
correspond to these areas - let us call it fo:flow-body:

<!ELEMENT fo:flow (fo:flow-body+ | (%block;)+)>

<!ELEMENT fo:flow-body+  (%block;)+>
<!ATTLIST fo:flow-body
          column-count CDATA #IMPLIED
          column-gap CDATA #IMPLIED
          ...
>

This would also yield the formatting more flexible - you could alternate
two-column regions with three-column ones. From the implementation point of
view, there's little difference between having only two possible values for
@column-count in a fo:flow, or having many - you still need to balance columns
in every span-reference-area separately. And  having a possibility to produce
magazine-style layouts is a big plus for any formatter.

Disposition: Accepted (clarification)

A clarifying note has been added in the description of the "span" property.

Links to the changed text in the XSL recommendation:

See link to changed text.

Best regards,
Nikolai Grigoriev
RenderX

Comment 5 (public comment): lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0138.html

From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de>
To: xsl-editors@w3.org
Date: Tue, 14 Nov 2000 20:22:19 +0100
Message-ID: <3A119EFB.7084.20A2B9@localhost>
Subject: space-treatment

Hello,

Item 1

in section 7.13.8 "space-treatment"

the enumeration of possible values of space-treatment in the xsl
definiton is not complete. the values ignore-if-before-linefeed etc.
are missing.

Disposition: Accepted (editorial)

This correction was already made in the Candidate Recommendation.

Item 2

imho the name space-treatment is rather unfortunate, because you
are talking about the handling of "white space" and you kept this
name for white-space-collapse

Disposition: Accepted (editorial)

The property has been renamed "white-space-treatment".

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

Fotis Jannidis

Comment 6 (public comment): lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0140.html

From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de>
To: xsl-editors@w3.org
Date: Thu, 16 Nov 2000 08:58:38 +0100
Message-ID: <3A13A1BE.14406.20E870@localhost>
Subject: errors

Hello,

Item 1

In 6.6.5 fo:external-graphic in list after "The following properties
apply to this formatting object:" the property [7.11.4 "display-align"]
is listed twice.

Disposition: Accepted (editorial)

This correction was already done in the Candidate Recommendation.

Item 2

In 7.11.4 "display-align" in the list "Applies to:
fo:table-cell, fo:region-body, fo:region-before, fo:region-after,
fo:region-start, fo:region-end" the fo external-graphic is missing or
the reference in 6.6.5 is wrong.

Disposition: Accepted (editorial)

The following have been added to the list: fo:block-container, fo:inline-container, fo:external-graphic, fo:instream-foreign-object

Links to the changed text in the XSL recommendation:

See link to changed text.

Fotis Jannidis

Comment 7 (public comment): lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0143.html

From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de>
To: xsl-editors@w3.org
Date: Sat, 18 Nov 2000 22:50:48 +0100
Message-ID: <3A1707C8.25558.141AC59@localhost>
Subject: error

Item 1

Hello,

in section 7.19.3 "leader-pattern-width"

The sentence

>>For leaders where the "leader-pattern" property is specified as
"dot" or as "use-content", this property will be honored.<<

must read:

>>For leaders where the "leader-pattern" property is specified as
"dots" or as "use-content", this property will be honored.<<

"dot" -> "dots"

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Fotis Jannidis

Comment 8 (public comment): lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0147.html

From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de>
To: xsl-editors@w3.org
Date: Mon, 20 Nov 2000 16:56:44 +0100
Message-ID: <3A1957CC.22626.1957541@localhost>
Subject: question

Hello,

Item 1

between xsl:fo wd from 12 January 2000

you changed the explanation for "leader-length" in section 7.14.4
from

"The specification of a minimum and maximum range of lengths
allows leaders and inline rules to be used to "fill" or "justify" a line
or to "fill" the remaining width of a table-cell. It also allows
for specification of how multiple leaders appearing in a given line-
area are to be balanced."

to section 7.19.4 in wd 18 October 2000

to "User agents may choose to use the value of "leader-
length.optimum" to determine where to break the line, then use the
minimum and maximum values during line justification."

My understanding of this option:
One of the common uses of the length-range leader-length will be to
construct table of contents. There the space between the text and
the page reference should be filled with dots or other characters.
Because of the different length of text and therefore the different
space for the filler you need some "fill" option and this is where the
length-range comes in.
I have been looking for some possibility to solve this problem and the
thought I could try it with using the length-range. By chance I
discovered that in earlier working drafts you explicitly mentioned this
usage. Have you changed plans? Should this effect now be
achieved by other means?

Disposition: Accepted (clarification)

Leaders are intended for use in table of contents "filed" with dots, so our plans have not changed. An example has been added to the specification showing this usage. In addition more note text has been added to clarify this usage.

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

Item 2

btw, there seems to be a superfluous " at the end of the sentence in
the latest wd.

Disposition: Accepted (editorial)

Fotis Jannidis

Comment 9 (public comment): lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0166.html

From: "Roger Neate" <alpha-dog@arfarfarf.com>
To: <xsl-editors@w3.org>
Date: Wed, 22 Nov 2000 09:57:37 -0800
Message-ID: <KJEEIHKPDLIHAJMJNFNDAEOKCCAA.alpha-dog@arfarfarf.com>
Subject: XSL Formatting Objects DTD or Schema

Item 1

Is there a downloadable DTD or schema for the formatting object elements as
specified in the XSL candidate recommendation 11 Nov 2000? I have been able
to find a DTD for the XSLT elements, but not for the formatting objects.
Thanks for any help you can offer.

Disposition: Explanation of why no change will be made

The XSL WG has not made any DTD (or schema) available for the formatting objects. The reason is that any such DTD would be rather meaningless (and maybe even misleading) since;

a) there are additional constraints on the content that cannot be expressed in a DTD, e.g., an fo:footnote is not permitted to have an fo:float, fo:footnote, or fo:marker as a descendant. To quote from the XSL specification:

The content of a formatting object is described using XML content-model syntax. In some cases additional constraints, not expressible in XML content models, are given in prose.

b) the formatting properties are syntactically expressed as XML attributes. Only some of the properties APPLY to a particular formatting object, but they can be specified on any formatting object (one very common case is to specify some number of inheritable properties close to the root of the tree and letting the values inherit down). Formatting properties may also be expressions, e.g., background-color="inherited-property-value(color)", so every attribute value would have to be declared as CDATA for a formatting object document to be validated by an XML processor. Thus a DTD would have to list all properties as permitted on each element and the only "validation" one would get is spelling of the attribute names!

Roger Neate

Comment 10 (public comment): lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0171.html

Date: Fri, 24 Nov 2000 19:01:14 GMT
Message-Id: <200011241901.TAA30585@cruzcampo.nag.co.uk>
From: David Carlisle <davidc@nag.co.uk>
To: xsl-list@mulberrytech.com
Subject: XSL-FO: syntax for datatypes

Item 1

I (rather late, sorry) noticed that in XSL-FO <integer> and <number>
literals (as specified on page 59 of the CR pdf file) allow an optional
+ before the digits. This is a rather surprising difference from XSLT
and XPath, considering how closely these specs are interrelated.
Probably the spec ought at least note the difference.

Disposition: Accepted (editorial)

The "+" is permitted for CSS2 compatibility. A note to that effect has been added to the specification.

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 2

Also (page 61) id and idref are defined to take a Name, and references
the XML spec for Name, however the namespace spec (rather weakly)
specifies that IDs should be NCNames.


     An XML document conforms to this specification if all other tokens
     in the document which are required, for XML conformance, to match
     the XML production for Name,
     match this specification's production for NCName.
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

         The effect of conformance is that in such a document:

        All element types and attribute names contain either zero or one
        colon.
        No entity names, PI targets, or notation names contain any colons.

    Strictly speaking, attribute values declared to be of types ID,
    IDREF(S), ENTITY(IES), and NOTATION are also Names, and thus should
    be colon-free.
       ^^^^^^^^^^

I believe that MSXML (at least) enforces this.

Disposition: Accepted (editorial)

IDs and IDREFs have been changed to NCNames.

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

David

(This message is being sent to xsl-list, copied to xsl-editors list)

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet delivered
through the MessageLabs Virus Control Centre. For further information visit

Comment 11 (public comment): lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0177.html

To: xsl-editors@w3.org
From: MURAKAMI Shinyu <murakami@nadita.com>
Message-Id: <200011270857.GGF08768.VBLNJSNB@nadita.com>
Date: Mon, 27 Nov 2000 08:57:18 +0900
Subject: XSL-FO - Initial value of border/padding conditionality

Item 1

The CR XSL 2000-11-21 says:

7.6.9 "border-before-width"
... The initial value of the .conditionality component is "retain".

7.6.12 "border-after-width"
... The initial value of the .conditionality component is "retain".

7.6.15 "border-start-width"
... The initial value of the .conditionality component is "discard".

7.6.18 "border-end-width"
... The initial value of the .conditionality component is "discard".

7.6.31 "padding-before"
... The initial value of the .conditionality component is "retain".

7.6.32 "padding-after"
... The initial value of the .conditionality component is "retain".

7.6.33 "padding-start"
... The initial value of the .conditionality component is "discard".

7.6.34 "padding-end"
... The initial value of the .conditionality component is "discard".

......


It lacks consistency!!!  Why "retain" on before/after and "discard" on
start/end?

I believe that the initial value of the .conditionality should be
"discard" on all edges.

Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0297.html

To: xsl-editors@w3.org
From: MURAKAMI Shinyu <murakami@nadita.com>
Message-Id: <200012301437.BGI52863.BJBNVNLS@nadita.com>
Date: Sat, 30 Dec 2000 14:37:18 +0900
Subject: Re: XSL-FO - Initial value of border/padding conditionality

Dear XSL-Editors,

I wrote:

>To: xsl-editors@w3.org
>From: MURAKAMI Shinyu <murakami@nadita.com>
>Message-Id: <200011270857.GGF08768.VBLNJSNB@nadita.com>
>Date: Mon, 27 Nov 2000 08:57:18 +0900
>Subject: XSL-FO - Initial value of border/padding conditionality
>
>The CR XSL 2000-11-21 says:
>
>7.6.9 "border-before-width"
>... The initial value of the .conditionality component is "retain".
>
>7.6.12 "border-after-width"
>... The initial value of the .conditionality component is "retain".
>
>7.6.15 "border-start-width"
>... The initial value of the .conditionality component is "discard".
>
>7.6.18 "border-end-width"
>... The initial value of the .conditionality component is "discard".
>
>7.6.31 "padding-before"
>... The initial value of the .conditionality component is "retain".
>
>7.6.32 "padding-after"
>... The initial value of the .conditionality component is "retain".
>
>7.6.33 "padding-start"
>... The initial value of the .conditionality component is "discard".
>
>7.6.34 "padding-end"
>... The initial value of the .conditionality component is "discard".
>
>......
>
>
>It lacks consistency!!!  Why "retain" on before/after and "discard" on
>start/end?
>
>I believe that the initial value of the .conditionality should be
>"discard" on all edges.
>

When I wrote that, I had not read [Disposition of Comments on
XSL 1.0 Last Call] yet, sorry.

http://www.w3.org/Style/XSL/XSL1/comments.html

>Disposition: Explanation of why no change will be made
>
>We agree that for many publishing applications the "discard"
>value is more commonly used. In CSS2, however, "retain" is
>the only behavior when a "block" is split. Thus we prefer to
>keep the initial value as "retain".
>

However, I cannot agree to this.

I could not find in CSS2 spec the behavior when a block is split.

Then, I tested major CSS implementations, MSIE 5.5, Netscape 6.0,
Opera 5.0, and I found "discard" is the behavior when a block is split
on all these products.

Therefore, I still believe that the initial value of the .conditionality
should be "discard" on all edges.


Regards,

MURAKAMI Shinyu
XSL-Dev, Antenna House, Inc.

Disposition: Accepted (clarification)

This question was discussed at a joint XSL/CSS face to face meeting and it was agreed that, even though the CSS2 recommendation does not state the behaviour for blocks being split one should assume the same rules as for inlines. The initial values have been changed to "discard" as you request.

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Regards,
MURAKAMI Shinyu

Comment 12 (public comment): lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0200.html

From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de>
To: xsl-editors@w3.org
Date: Sat, 2 Dec 2000 14:55:15 +0100
Message-ID: <3A290D53.10638.E38766@localhost>
Subject: typo

Item 1

In section 7.20.5 "rule-style"

>>>
double:
The rule is two solid lines. The sum of the two lines and the space
between them eqThe rule is two solid lines. The sum of the two lines
and the space between them equals the value of "rule-thickness".
<<<

The texts has been inserted twice and broken too.

Disposition: Explanation of why no change will be made

The doubling is not present in the HTML files, nor in the PDF version of the Candidate Recommendation. Was the incorrect display a browser (or other User Agent) error?

Fotis Jannidis

Comment 13 (public comment): lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0259.html

From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de>
To: xsl-editors@w3.org
Date: Thu, 14 Dec 2000 23:09:33 +0100
Message-ID: <3A39532D.22475.32254E4@localhost>
Subject: typo

Item 1

In: 7.28.1 "background"

Applies to: all elemeall elements

Disposition: Explanation of why no change will be made

The doubling is not present in the HTML files, nor in the PDF version of the Candidate Recommendation. Was the incorrect display a browser (or other User Agent) error?

Fotis

Comment 14 (public comment): lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0280.html

Message-Id: <4.3.1.2.20001223105334.00ba3c20@127.0.0.1>
Date: Sat, 23 Dec 2000 11:01:19 +0000
To: xsl-editors@w3.org
From: Dave Pawson <daveP@dpawson.freeserve.co.uk>
Subject: master-name property

Item 1

The use of the master-name property within
fo:simple-page-master ,  fo:page-sequence-master and fo:page-sequence
I find very confusing.

Within fo:single-page-master-reference you specify master-name, but
element indicates its a reference, not a 'name' or identifier.
For the previous 3 elements, I'm not sure if each is a reference or
an identifier.

I would find it far more helpful if the property were changed to
clearly indicate to users that the first two are idenfiers,
and in the third case its a reference, perhaps by changing the
property name to master-name-reference. If this is done, the practice
could be made common by renaming the master-name property in the sub-sequence
elements of page-sequence-master.

E.g.

  <fo:page-sequence-master master-name="master-sequence">
          <fo:single-page-master-reference
             master-name-reference="first"/>
           <fo:repeatable-page-master-reference
                 master-name-reference="red"
                 maximum-repeats="10"/>
           <fo:repeatable-page-master-reference
                 master-name-reference="green"
                maximum-repeats="no-limit"/>
   </fo:page-sequence-master>


Then fo:page-sequence would read

<fo:page-sequence
    master-page-reference="master-sequence"

Its difficult enough to understand without adding to the complexity
by misleading readers with poorly named properties.

Disposition: Accepted (clarification)

"master-name" has been changed to "master-reference" on the FOs that refer. "master-name-reference" was rejected to avoid "x" and "x-qualified" names. "master-page-reference" was rejected as the value can be referring to either a page master or a sequence master.

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Regards DaveP
AC, RNIB.

Comment 15 (public comment): lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0298.html

Message-Id: <4.3.1.2.20001230164305.00bbe830@127.0.0.1>
Date: Sat, 30 Dec 2000 16:50:49 +0000
To: xsl-editors@w3.org
From: Dave Pawson <daveP@dpawson.freeserve.co.uk>
Subject: fo:if ! feature request

Not sure its 1.0, but definately for 1.1/2.0, whichever is next.

Item 1

Use case:

We (RNIB, www.rnib.org.uk) print large print bank statements for
our customers.

I had to pass when a chance came up to use XML/XSL-FO because a simple
requirement could not be met.

The table of date/item/amount has, at the top of each page a 'sum' of
transactions to date.
NO NOT IN THE HEADER. fo:marker won't do it.

In the body of the content, I needed a simple calculation to say
'transactions to date' . XSLT allows me to calculate it, but XSL won't
allow me to add the content at the right time.

We need interaction with the formatter.

Requirement.
That it be possible to interface with the formatter to insert content
as and when 'top of new page' is true.

Syntax down to you, I envisage something like

<fo:if test="top-of-page">
   <fo:block/>
</fo:if>

I want the conditional block to be available as and when the formatter
has determined that a new page is 'about to start', so I can get my
odd bits in at the right place.

Disposition: Future XSL version

The functionality asked for is one aspect of a much larger area of "layout driven" formatting. The XSL WG decided not to include it in 1.0 but it will be considered for a subsequent XSL version.

If I'm not clear in the requirement/use case, please come back to me
with questions.

I would appreciate an acknowledgement.

Regards DaveP
AC RNIB.

Comment 16 (public comment): lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0299.html

Message-ID: <3A4E8A6F.79697108@metalab.unc.edu>
Date: Sat, 30 Dec 2000 17:22:55 -0800
From: Elliotte Rusty Harold <elharo@metalab.unc.edu>
To: xsl-editors@w3.org
Subject: fo:page-sequence; How many fo:flow children can it have?

Item 1

In section 6.4.5, fo:page-sequence, the content model is given as:

(title?,static-content*,flow)

This says that each fo:page-sequence has *exactly one* fo:flow child
element.

However, the prose in that section repeatedly refers to "the child
fo:flow objects", the "flow children of the fo:page-sequence", "the
flow-object children of the fo:page-sequence", and other plural forms of
fo:flow that suggest a fo:page-sequence can have more than one fo:flow
child. I suspect the content model for fo:page-sequence should be

(title?,static-content*,flow+)
                           ^^^

Or if not, then the prose should be tightened up to indicate that at
most one fo:flow is allowed in each fo:page-sequence.

Disposition: Accepted (clarification)

The intent is to have only ONE fo:flow per fo:page-sequence. The text has been "tightened" to reflect that. Note, however, that "flow" (as opposed to fo:flow) refers to content from both fo:flow and fo:static-content and it does occur in the plural intentionally.

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|               Java I/O (O'Reilly & Associates, 1999)           |
|            http://metalab.unc.edu/javafaq/books/javaio/            |
|   http://www.amazon.com/exec/obidos/ISBN=1565924851/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java news:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML news: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

Comment 17 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0008.html

Message-ID: <3A54F6A2.503C04B4@club-internet.fr>
Date: Thu, 04 Jan 2001 23:18:10 +0100
From: Karen Lease <klease@club-internet.fr>
To: xsl-editors@w3.org
Subject: fo:block-container, padding and borders- request for clarification

Hello,

Item 1

I'd like to make sure I have the correct understanding of how to handle
padding and border on block-container formatting objects.

In section 6.5.3 I read:
"The fo:block-container formatting object generates one or more
viewport/reference pairs.
...
The following properties apply to this formatting object:
  [7.4 Common Absolute Position Properties]
  [7.6 Common Border, Padding, and Background Properties] "

In the general explanation of the area model (Chapter 4.9.4), it says
that the border is not rendered for areas which are children of
viewport-areas.
Since border and padding can be specified on block-container, should
they be applied to the viewport-area?

For example, suppose I have an absolutely positioned block-container.
The values for left,top etc. position its content rectangle. Assuming no
scrolling, the content rectangle for the reference area and its parent
viewport area should be the same (at least their start and before edges
are the same). If non-zero padding and border were specified for the
block container, are they to be rendered outside the content rectangle
of the viewport area?

Disposition: Explanation of XSL spec

The answer to both your questions is yes. The border and padding should be applied to the viewport-area and rendered outside its content rectangle.

Thanks in advance,

Karen Lease, FOP'er

Comment 18 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0009.html

Message-ID: <3A54FF06.A6DF2976@club-internet.fr>
Date: Thu, 04 Jan 2001 23:53:58 +0100
From: Karen Lease <klease@club-internet.fr>
To: xsl-editors@w3.org
Subject: Inherited values where percent is legal

Hello,

Item 1

In working on FOP's FO property handling, I've run across a few issues
involving lengths which can be specified as percentages, especially when
the property can be inherited.
My list of such properties and their reference dimensions is as follows:

start-indent, end-indent             width of containing reference area
text-indent, last-line-text-indent   width of containing block
line-height                          font-size of the FO (inherits
specified?)
font-size                            font-size of parent (inherits
computed)
leader-length                        width of content-rectangle of
parent area
leader-pattern-width                 width of containing box
provisional-distance-between-starts  width of containing box
provisional-label-separation         width of containing box

I know that the general rule is that computed values are inherited. This
is explicitly stated for font-size. On the other hand, for line-height,
when it is specified as a number the specification says that the
specified value is inherited. In this case, I'm inclined to treat a
percentage in the same way as a number (and a relative length too for
that matter).
For the other properties above, there is no specific mention of the
inherited value, implying that the computed value is inherited.

This bothers me a bit, especially for a property like leader-length
where the default value for leader-length.maximum is "100%". I would
feel more comfortable if the specified percentage value were inherited
and recalculated on each flow object.

I'd appreciate any explanations or justifications you can offer for
this.

Disposition: Explanation of XSL spec

For compatibility with CSS2 the general rule, even for percentages, is that the computed value is inherited. We have added a section specifying in detail which area is used as reference when the "general rule" is not sufficient, e.g. a percentage specified on fo:root.

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 2

A related question: in the list above, there are several different ways
of designating the base length for a percentage. My interpretation is :
a) the dimension in question is always the content-rectangle, unless
explicitly stated otherwise,
b) "containing block" means the nearest block-area ancestor
c) "containing box" and "parent area" are basically equivalent and could
be either an inline-area or block-area.

Is this correct? Or is there some distinction I'm missing?

Disposition: Accepted (bug in spec)

A section has been added to specify in detail which rectangle (which in almost all cases is the content-rectangle) is used as reference for the calculation of the computed value of a percentage. The different ways it was designated in the text has been rationalized.

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Thanks in advance for any information,

Karen Lease, FOP'er

Comment 19 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0022.html

Message-ID: <3A59C4E4.EED525AA@isu-gmbh.de>
Date: Mon, 08 Jan 2001 14:47:16 +0100
From: Christian Geisert <Christian.Geisert@isu-gmbh.de>
To: xsl-editors@w3.org
Subject: fo:inline - no text-transfom/text-shadow?

Hi,

Item 1

I'm wondering why the formatting properties "text-transform" and "text-shadow"
are not in the list of properties which apply to fo:inline? (see 6.6.7)

Disposition: Explanation of XSL spec

These properties apply to the content, fo:character, of the fo:inline and not to the inline itself.

These properties have been removed from "bidi-override" for the same reason.

Christian Geisert

Comment 20 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0029.html

To: xsl-editors@w3.org
Cc: xsl-list@lists.mulberrytech.com
From: MURAKAMI Shinyu <murakami@nadita.com>
Message-Id: <200101100311.EDC35279.BSLVJNNB@nadita.com>
Date: Wed, 10 Jan 2001 03:11:39 +0900
Subject: XSL-FO - start-indent and end-indent

I've found some problems of XSL-FO CR spec about start-indent and end-indent.

Item 1

Problem 1: Formulae for indents (indent=margin+padding+border?)
===============================================================

In [5.3.2 Margin, Space, and Indent Properties] of XSL-FO CR spec:
<quote>
The formulae for calculating the computed value of the "start-indent",
and "end-indent" properties are as follows (where "margin-corresponding"
is a variable for the corresponding absolute "margin" property):

end-indent = margin-corresponding + padding-end + border-end-width
start-indent = margin-corresponding + padding-start + border-start-width
</quote>

I understand that the margin- properties and the above formulae are
provided for compatibility with CSS.
However the compatibility is imperfect.

Case 1: Indents on nested blocks

CSS (with HTML):
<div style="margin-left: 0pt; padding-left: 9pt; border-left: 6pt solid red">
  Outer Block
  <div style="margin-left: 0pt; padding-left: 9pt; border-left: 6pt solid blue">
    Inner Block
  </div>
</div>

Formatted as:
| Outer Block
| | Inner Block

XSL-FO (simply converted):
<fo:block margin-left="0pt" padding-left="9pt" border-left="6pt solid red">
  Outer Block
  <fo:block margin-left="0pt" padding-left="9pt" border-left="6pt solid blue">
    Inner Block
  </fo:block>
</fo:block>

Then, let's calculate the start-indents using the formula:

  start-indent = margin-corresponding + padding-start + border-start-width
    = 0pt + 9pt + 6pt = 15pt  (on both outer and inner blocks)

and the equivalent XSL-FO will be:

<fo:block start-indent="15pt" padding-left="9pt" border-left="6pt solid red">
  Outer Block
  <fo:block start-indent="15pt" padding-left="9pt" border-left="6pt solid blue">
    Inner Block
  </fo:block>
</fo:block>

Formatted as:
| Outer Block
| Inner Block

Problem: Both start-indents have same value and the two borders overlap.
(because indents are measured from the containing reference-area, not the
containing block)

To solve the problem
--------------------
The formulae should be corrected as:
  end-indent = inherit + margin-corresponding + padding-end + border-end-width
  start-indent = inherit + margin-corresponding + padding-start + border-start-width

Then,

  outer block: (here, inherit=0pt)
    start-indent = 0pt + 0pt + 9pt + 6pt = 15pt

  inner block: (here, inherit=(outer start-indent)=15pt)
    start-indent = 15pt + 0pt + 9pt + 6pt = 30pt

<fo:block start-indent="15pt" padding-left="9pt" border-left="6pt solid red">
  Outer Block
  <fo:block start-indent="30pt" padding-left="9pt" border-left="6pt solid blue">
    Inner Block
  </fo:block>
</fo:block>

and the formatted results are same as the original.

Disposition: Accepted (bug in spec)

The formula has been corrected by adding "inherited end-indent +" and "inherited start-indent +" respectively.

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 2

Case 2: Indents on blocks without margin-corresponding specified

On the previous case, I did not omit margin-left:0pt.  In CSS, it can
be omitted because zero is the initial value of margin- properties and
these are not inheritable.  But in XSL-FO, it's not so easy since
start- and end-indent are inheritable.

In CSS (with HTML):
<div style="padding-left: 9pt; border-left: 6pt solid red">
  Outer Block
  <div style="padding-left: 9pt; border-left: 6pt solid blue">
    Inner Block
  </div>
</div>

Formatted as:
| Outer Block
| | Inner Block
(same as when margin-left:0pt is specified on both block)

In XSL-FO (simply converted):
<fo:block padding-left="9pt" border-left="6pt solid red">
  Outer Block
  <fo:block padding-left="9pt" border-left="6pt solid blue">
    Inner Block
  </fo:block>
</fo:block>

The problem is how to get the start-indent values.
Since the margin-corresponding (margin-left) is not specified, the
formulae for indents are not applicable.  In the XSL-FO spec,
start/end-indent properties are inheritable and its initial value is 0pt.
Therefore, start-indent="0pt" is the answer (?)

If this is the correct interpretation, the above XSL-FO is equivalent to:

<fo:block start-indent="0pt" padding-left="9pt" border-left="6pt solid red">
  Outer Block
  <fo:block start-indent="0pt" padding-left="9pt" border-left="6pt solid blue">
    Inner Block
  </fo:block>
</fo:block>

Formatted as:
Outer Block
Inner Block
(borders are outside of the containing reference-area!!)

The results are very different from the original CSS.

I think this is very serious problem of compatibility with CSS.

To solve the problem
--------------------
The formulae should be used although margin-corresponding are not
explicitly specified.

  end-indent = inherit + margin-corresponding + padding-end + border-end-width
  start-indent = inherit + margin-corresponding + padding-start + border-start-width
  (in this case, margin-corresponding defaults to 0pt)

Then, the start-indents are computed as follows:
  outer block: (here, inherit=0pt)
    start-indent = 0pt + 0pt + 9pt + 6pt = 15pt

  inner block: (here, inherit=(outer start-indent)=15pt)
    start-indent = 15pt + 0pt + 9pt + 6pt = 30pt

The omitted start-indents are filled as follows:

<fo:block start-indent="15pt" padding-left="9pt" border-left="6pt solid red">
  Outer Block
  <fo:block start-indent="30pt" padding-left="9pt" border-left="6pt solid blue">
    Inner Block
  </fo:block>
</fo:block>

Disposition: Explanation of XSL spec

In XSL you have to explicitly specify margin=0 in order for the indent to be computed from the margin value. start- and end-indents are inherited properties and the traits are the indents not the margins. The current text has been expanded to make the computation rules clearer.

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 3

Problem 2: Inherited start-indent and end-indent on reference areas
===================================================================

This problem has already been pointed out by other people.
In http://www.renderx.com/Tests/doc/html/spec.html [XSL FO in XEP 2.01]
<quote>
Another situation where holistic inheritance scheme adopted in XSL FO CR
produces indesirable side effects. According to the spec, indents are
inherited from fo:table to its descendants, i.e. table cells. But inside
cells, indents are measured from another reference edge! Apparently, this
has the following effect: when you specify an indent for the table, the
contents of each cell is shifted by the same amount from the edge of the
cell.

In XEP 2.01, the inheritance is broken at this point: if an object
introduces a new reference area, start-indent and end-indent for it are
not inherited from its parent. In particular, this applies to fo:table-
cell, fo:block-container, and fo:inline-container.
</quote>

In my implementation, too.

Disposition: Explanation of why no change will be made

The design approach taken for XSL was to have a simple inheritance model. Making this change would obviously introduce an exception to this model. There are many other properties that one MIGHT not want to inherit from e.g. a table-and-caption to the content of the cells so why single out indent? If one, for example, wants to center a table-and-caption one specifies text-align="center" for the table-and-caption, which inherits to the cells.

There are also cases where it is necessary to be able to use the value of an indent value in effect outside a reference area inside it. One example is for "CSS side floats" where the floated object is to have the same indent as where the float was defined. In XSL this means that the indent of the content of the reference area generated by the fo:float should be the same as the indent of the fo in which the float occurred. In other cases, eg when using an "offset" style where paragraphs are indented, but "headings" are not, it is also more convenient to inherit the indents.

The consensus of the working group was to not introduce this breaking of the inheritance as it is sometimes very useful and in the cases where it is not what the stylesheet author wishes it is very easy to make an explicit specification of the desired indent. An example, using attribute-sets, has been added to the specification to show this.

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 4

Problem 3: Indents on list-item-label and list-item-body
========================================================

As shown in the above, inherited start- and end-indent values are
sometimes not useful and should be modified.

I request the following modification for solving the problem of inherited
indents on list-item-label and list-item-body (label and body overlap
when indents are not specified).

on list-item-label:
  end-indent defaults to label-end()
on list-item-body:
  start-indent defaults to body-start()

Then,

<fo:list-block>
  <fo:list-item>
    <fo:list-item-label>
      <fo:block>(1)</fo:block>
    </fo:list-item-label>
    <fo:list-item-body>
      <fo:block>List Item Body</fo:block>
    </fo:list-item-body>
  </fo:list-item>
</fo:list-block>

is now not an error and equivalent to:

<fo:list-block>
  <fo:list-item>
    <fo:list-item-label end-indent="label-end()">
      <fo:block>(1)</fo:block>
    </fo:list-item-label>
    <fo:list-item-body start-indent="body-start()">
      <fo:block>List Item Body</fo:block>
    </fo:list-item-body>
  </fo:list-item>
</fo:list-block>

Disposition: Explanation of why no change will be made

The working group felt that also in this case it was better to preserve the simple inheritance model.

Conclusion
==========

This comment contains some requests to XSL-FO spec, and these features have
already been built into my implementation, as well as my last comments:

"XSL-FO - Initial value of border/padding conditionality"
http://lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0297.html

Therefore, my implementation does not completely conform to the XSL-FO CR.
IMHO, the XSL-FO spec is not complete yet and should be improved.


Regards,

MURAKAMI Shinyu
"Antenna House XSL Formatter" - http://www.antennahouse.com/xslformatter.html

Comment 21 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0039.html

From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de>
To: xsl-editors@w3.org
Date: Fri, 12 Jan 2001 16:04:32 +0100
Message-ID: <3A5F2B10.2214.DE6DC2@localhost>
Subject: small errors

Item 1

In the following 2 paragraphs from section 6.10.1.3 it should be
"flow-name" instead of "region-name"

"If there is a fo:static-content in a page-sequence whose "region-
name" property value is"xsl-before-float-separator", then the
areas returned by formatting thefo:static-content are inserted in
the proper order as the last children ofa before-float-reference-
area that is generated using the same page-master,provided the
main-reference-area on the page is not empty.
If there is an fo:static-content whose "region-name" property value
is"xsl-footnote-separator", then the areas returned by formatting
thefo:static-content are inserted in the proper order as the initial
children ofa footnote-reference-area that is generated using the
same page-master.

Disposition: Accepted (editorial)

"region-name" changed to "flow-name" in two places.

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

Fotis Jannidis

Comment 22 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0040.html

From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de>
To: xsl-editors@w3.org
Date: Fri, 12 Jan 2001 16:25:29 +0100
Message-ID: <3A5F2FF9.11052.F19CF6@localhost>
Subject: small errors 2 (delete 1)

Item 1

In the following 2 paragraphs from section 6.10.1.3 there is some problem.
Either it should be "flow-name" instead of "region-name" in both
cases, or the first paragraph is correct as it is (besides of 'a fo:' ->
'an fo:'), but then the sentence part "whose "region-
name" property value is"xsl-before-float-separator"" refers to the
page-sequence and I understood that the 'xsl' prefix is mostly used
in flow-names. imho the second paragraph has to be corrected in
any case.

"If there is a fo:static-content in a page-sequence whose "region-
name" property value is"xsl-before-float-separator", then the
areas returned by formatting thefo:static-content are inserted in
the proper order as the last children ofa before-float-reference-
area that is generated using the same page-master,provided the
main-reference-area on the page is not empty.
If there is an fo:static-content whose "region-name" property value
is"xsl-footnote-separator", then the areas returned by formatting
thefo:static-content are inserted in the proper order as the initial
children of a footnote-reference-area that is generated using the
same page-master."

Disposition: Accepted (editorial)

"region-name" should be changed to "flow-name" in both places.

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

Item 2

btw, I don't think it would be horrible redundant to list all the flow-
names which xsl:fo predefines (like xsl-region-body, xsl-region-
before, xsl-before-float-separator, xsl-footnote-separator etc.) in
section 7.24.5

Disposition: Accepted (editorial)

The list has been added as a note.

Links to the changed text in the XSL recommendation:

See link to changed text.

Fotis Jannidis

Comment 23 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0041.html

From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de>
To: xsl-editors@w3.org
Date: Fri, 12 Jan 2001 16:42:53 +0100
Message-ID: <3A5F340D.32587.1018A45@localhost>
Subject: addition to last msg

Item 1

In the following paragraph from section 6.4.1.4. the spec also uses
"region-name" instead of "flow-name":

>>>
In addition, an fo:static-content formatting object may have a
"region-name" property value of "xsl-before-float-separator" or "xsl-
footnote-separator".  If a conditional sub-region of the region-body
is used to generate a reference-area on a particular page, the
fo:static-content whose name corresponds to the conditional sub-
region shall be formatted into the reference-area associated with
the sub-region, as specified in section [6.10.1.3 Conditional Sub-
Regions].
<<<

Disposition: Accepted (editorial)

"region-name" changed to "flow-name".

Links to the changed text in the XSL recommendation:

See link to changed text.

fj

Comment 24 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0045.html

From: AndrewWatt2001@aol.com
Message-ID: <14.e638c3f.27956ce0@aol.com>
Date: Tue, 16 Jan 2001 04:22:40 EST
To: XSL-FO@egroups.com
CC: xsl-editors@w3.org
Subject: Re: [XSL-FO] 1.1.2  Formatting ...please help

Item 1

In a message dated 16/01/01 03:01:30 GMT Standard Time, r_diblasi@hotmail.com
writes:

Hi Robert,

My $0.02 follows below.

> Hello,
>
>     What the hell.........I have been reading this sentence over and
>  over
>  and I understand each part but I do not understand the whole.....
>
>  Formatting 1.1.2
>      "Formatting interprets the result tree in its formatting object
>  tree form to produce the presentation intended by the designer of the
>  stylesheet from which the XML element and attribute tree in the "fo"
>  namespace was constructed."

I think the short answer is that it is a badly drafted sentence. There are,
IMHO, more than a few them in the current XSL-FO CR. If you examine the
XSL-FO CR you will see that there is no identified "editor", unlike the
position with a typical W3C spec in development. The absence of mention of an
identified editor seems to be reflected in the absence, at this stage, of
consistently tight editing of the text.

>  I think the last part is driving me crazy.....
>
>  "the stylesheet from which the XML element and attribute tree in
>  the "fo" namespace was constructed."

I think you have probably broken the sentence at the wrong place. Having said
that try reading the whole sentence replacing "stylesheet from which" with
"stylesheet using which". That is closer to what I think the editors mean.

>  Someone with a good heart help me.....
>
>  I believe it to mean
>      Formatting interprets the result tree in its formatting object
>  form......(with Formating objects in the the result tree) .....
>  to product the presentation intended by the designer of the
>  spreedsheet.......it all goes to hell after this point :-)....

BTW when writing out the sentence you replace "produce" with "product" which
makes it worse. :)

LOL ... I have just scrubbed the reply I was about to make. I thought I had
cracked it, but then it slipped through my fingers. :) Proves your point I
guess. It's a horrible sentence. :)

My attempt at a better version:

"Formatting is the final step of a multi-step process. The first step is the
production of an XML element and attribute tree (also known as a "result
tree"), using an XSL style sheet and XML source document. The result tree is
"objectified" into a tree in the XSL-FO Namespace. Formatting is the process
of interpreting the result tree (the XML element and attribute tree), in its
formatting object form, into a display [or visual presentation].".

Just my $0.02.

I would also say that for the XSL editors to attempt to equate the
"intention" of the designer with the actual process of
formatting/presentation is unwise. That only applies if the designer
correctly writes a stylesheet to actually produce the result.

In addition there is a further background suspicion I have (but haven't yet
had time to look at properly) - that the term "formatting" is being used in
more than one sense in the XSL-FO CR.

>  Help....
>  Robert A. DiBlasi

I hope that's clearer. BTW if you look at the diagram a little later in
Section 1.1.2 that might help you visualise it.

I have copied this reply to the XSL-editors at W3C. Hopefully they will take
the problems with this sentence into account when further drafting/editing
takes place. And if we have both failed to understand the meaning that is
intended they may, hopefully, provide a response which can be posted on list.

Discussion message: lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0048.html

From: AndrewWatt2001@aol.com
Message-ID: <1e.100a798d.2796045d@aol.com>
Date: Tue, 16 Jan 2001 15:09:01 EST
To: XSL-FO@egroups.com
CC: xsl-editors@w3.org
Subject: Re: [XSL-FO] Re: 1.1.2  Formatting ...please help

In a message dated 16/01/01 19:14:49 GMT Standard Time, r_diblasi@hotmail.com
writes:

> "with objects primarily in the "formatting object" namespace."????
>
>  What is the spec trying to say????

Robert,

Due to time constraints I will respond only to this question at present.

The XSL-FO spec uses three terms (as I read it) for the same thing - in each
case the namespace URI is http://www.w3.org/1999/XSL/Format.

The spec, as I recall, uses three terms each of which appears to me to refer
to that same namespace URI and therefore mean the same.

The three terms are:

 1. XSL Namespace
 2. "fo" namespace
 3. "formatting objects" namespace

I am doing all this from memory so forgive me if I slip up on a word or two.

The spec also goes on to refer to "the" XSL Namespace.

But there are, in fact, two "XSL" Namespaces. XSL consists of both XSLT and
XSL-FO. The CR needs to edited more tightly in my opinion to reflect that
reality.

There is (my terms)
1. An XSLT namespace for which the namespace URI is
http://www.w3.org/1999/XSL/Transform
and
2. An XSL-FO namespace for which the namespace URI is
http://www.w3.org/1999/XSL/Format

Since both XSLT and XSL-FO **together** constitute "XSL" we have two distinct
"XSL" namespaces with the respective namespace URIs which I have just given.

In my view the XSL spec editors need to take that on board and introduce
greater precision and  consistency in the use of terms.

I posted on another list recently about a related issue. I will try to dig
that out and post it within the next hour or two.

Andrew Watt

Discussion message: lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0049.html

From: AndrewWatt2001@aol.com
Message-ID: <55.fe42611.27960c74@aol.com>
Date: Tue, 16 Jan 2001 15:43:32 EST
To: XSL-FO@egroups.com
CC: xsl-editors@w3.org
Subject: A need for consistency and precision when referring to "XSL"

Robert & others,

The issue addressed in this post may go some way to help some list members
understand  why they are having problems understanding parts of the "XSL"
Candidate Recommendation, which in my view would be better termed as the
"XSL-FO" CR.

What follows is a slight re-edit of a past post on another list.

***Re-edited quote begins***

This post is a plea for a beginning in consistent use of the term "XSL" in
W3C documents. The current CR stage of XSL-FO and the first WD of XSLT 1.1
give an opportunity to W3C to remove longstanding inconsistent usage and to
introduce coherence and consistency.

For those who have not yet considered the problem let me summarise the
difficulty and inconsistency by the use of two "equations" which summarise
two mutually contradictory positions about what "XSL" is which are taken
(implicitly or explicitly) in the current versions of W3C documents.

To avoid ambiguity I use the term "XSLT" to indicate XSL Transformations and
the term "XSL-FO" to indicate XSL Formatting Objects.

The two equations are:
 1.    XSL = XSLT + XSL-FO (see e.g. Abstract of XSL-FO CR)
 2.   XSL = XSL-FO

Stated as baldly as this I expect to potentially elicit howls of protest
along the lines
of "Of course XSL is the summation of XSLT and XSL-FO". But the statements
currently present in various W3C documents contradict this assumed clarity
and consistency.

Let me illustrate. .... In the XSLT 1.0 Recommendation of November 1999 it is
stated in the Abstract, "XSLT is also designed to be used independently of
XSL.", a statement which cannot be true if XSL = XSL-FO + XSLT (XSLT cannot
be used independently of "XSL" since XSLT is _part of_ "XSL") and
contradicts, for example, the Abstract of the XSL-FO CR. However the
statement also
contradicts the position taken earlier in the Abstract of XSLT 1.0: "In
addition to XSLT, XSL includes ....". So, XSLT seems to be "included in" XSL
but
is also can be used "independent of" it. Something doesn't add up. What is
happening is that the first part of the preceding sentence refers implicitly
to equation 1. and the latter part to equation 2.

Thus, in theXSLT 1.0 Recommendation (and repeated verbatim in the XSLT 1.1
WD) we have the use of both "equations". Which equation is true? Does XSL =
XSL-FO + XSLT or is XSL = XSL-FO? XSLT 1.0 effectively uses these two mutually
contradictory positions within a few lines of each other.

The same inconsistency also appears in the current XSL-FO CR. As mentioned
above the Abstract indicates unequivocally that XSL includes both XSLT and
XSL-FO. But in Section 2, confusingly labelled "Introduction to XSL
Transformations" it is stated, "The XSL namespace has the URI
http://www.w3.org/1999/XSL/Format.". The placement of a statement about what
I would call the XSL-FO namespace in a section on XSLT is confusing enough.
But if, as the Abstract of the CR implicitly states, XSL = XSL-FO + XSLT then
there are two "XSL" namespaces viz. http:www.w3.org/1999/XSL/Format AND
http://www.w3.org/XSL/Transform, not one as the XSL-FO CR states.

There are many ways of slicing up these inconsistencies but, in my view, they
are founded in the use of "XSL" in the same documents to have two distinct
meanings. Is "XSL" the same as "XSL-FO + XSLT"? Or is "XSL" the same as
"XSL-FO"?

I would suggest that the W3C "XSL" editors ... by which I mean the editors
for the XSL-FO CR and the new XSLT 1.1 WD need to decide what "XSL" is and
then use the term precisely and consistently. At present neither precision
nor consistency is achieved.

I hope these two examples serve to illustrate the ambiguity or inconsistency
of the use of the term "XSL" in current W3C documents. I could, quite
possibly, go on at length about how the inconsistency plays out in various
W3C documents. Rather, I think it is more important to find a solution that
is logical, clear and consistent.

Suffice to say that the inconsistency within XSL/XSL-FO/XSLT specs plays out
to some degree in other specs too.

My suggestion for how to move toward coherence would be:

1. Confine the generic term "XSL" to situations which refer to XSLFO _and_
XSLT collectively.
2. When referring to XSL Formatting Objects the abbreviation to be used
should be either "XSL-FO" or "XSLFO".
3. When referring to XSL Transformations the abbreviation used should be
"XSL-T" or "XSLT".
4. It should be recognised that there are two "XSL Namespaces". The XSLT
Namespace has a namespace URI of http://www.w3.org/1999/XSL/Transform. The
XSL-FO Namespace has a namespace URI of http://www.w3.org/1999/XSL/Format.
5. The confusing "indicative prefix" (my term) for those two namespaces
should be corrected/made consistent. I would suggest that the XSLT namespace
use the "indicative prefix" of "xslt" rather than "xsl" i.e. as an example,
the present
<xsl:stylesheet> element would become <xslt:stylesheet>. Similarly the "fo"
indicative prefix would become "xslfo" i.e. <fo:root> would become
<xslfo:root>.

I would propose that the W3C Core XML Group (do I have the terminology
correct?) review the current inconsistency in terminology across W3C specs
currently in draft or under revision and give clear, unambiguous guidance on
which meaning "XSL" has in W3C documents.

<side_issue>
[ With regard to the more specific problem relating to the naming of the
current XSL-FO CR could that not be called the "Extensible Stylesheet
Language Formatting Objects, XSL-FO" Recommendation in due time? And could
another very short "XSL" REC indicate that XSL version 1.0 subsumes the XSLT
REC of November 1999 and the XSL-FO REC, currently at CR stage? Then when
XSLT 1.1 is finalised "XSL 1.1" could be defined as "XSL-FO 1.0" plus "XSLT
1.1"? Just a thought. :) ]
</side_issue>

Consistent usage of the term "XSL" is desirable. With the current fluidity of
a XSL-FO CR and an XSLT 1.1 WD there is an early opportunity for W3C to
introduce consistency where hitherto inconsistent and confusing usage of the
term "XSL" has been rather too visible.

*** Re-edited quote ends ***

Returning to Robert's question about the "fo" namespace and the confusion
that that term caused him - If my suggestions were adopted we would refer to
that as the XSL-FO namespace with, in my view, much less ambiguity than a
supposed but essentially spurious "XSL namespace".

Sorry, to those for which this is pretty hard going. You need to be fairly
familiar with how the specs use the terms to see that there is a problem. And
perhaps more familiar to diagnose it and suggest a (hopefully coherent)
remedy.

I hope that the XSL-editors wil prove responsive to these suggestions. It
would make teaching some parts of XSL/XSL-FO/XSLT to relative beginners just
a little bit easier if the "standard" terms were used consistently in the
definitive documents.

Andrew Watt

Discussion message: lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0056.html

To: AndrewWatt2001@aol.com
Cc: XSL-FO@egroups.com, xsl-editors@w3.org
From: Max Froumentin <mf@w3.org>
Date: 22 Jan 2001 12:43:48 +0100
Message-ID: <878zo37qx7.fsf@sophia.inria.fr>
Subject: Re: A need for consistency and precision when referring to "XSL"

AndrewWatt2001@aol.com writes:

> XSLT cannot be used independently of "XSL" since XSLT is _part of_
> "XSL"

Why not? XPath is part of XSLT, but is used independently (by XLink,
as it happens).

> Does XSL = XSL-FO + XSLT or is XSL = XSL-FO?

XSL = XSLT + XPath + XSL, hence XSLT+XPath=0!  Just kidding :) XSL
includes XSLT, and that's the only 'equation' one should write (or you
could as well write XSL = XSLT+Xpath+FOs+CSS+XMLNameSpaces+XML, etc.)

> The same inconsistency also appears in the current XSL-FO CR.

Again, I don't see why a subset of a spec can't be used independently
and hence use a different namespace.

> At present neither precision nor consistency is achieved.

It seems that things would be clearer to you if XSL was renamed XSL-FO
or something similar and if the two specs were made independent. Well,
one doesn't want that, as that would mean that XSL-FO can be used
without XSLT, and that is just Wrong (as it's explained in the XSL
spec).

> 1. Confine the generic term "XSL" to situations which refer to XSLFO
> _and_ XSLT collectively.

It seems to me that this is most people's understanding.

> 2. When referring to XSL Formatting Objects the abbreviation to be
> used should be either "XSL-FO" or "XSLFO".

That's also the case.

> 3. When referring to XSL Transformations the abbreviation used
> should be "XSL-T" or "XSLT".

ditto.

> 4. It should be recognised that there are two "XSL Namespaces". The
> XSLT Namespace has a namespace URI of
> http://www.w3.org/1999/XSL/Transform. The XSL-FO Namespace has a
> namespace URI of http://www.w3.org/1999/XSL/Format.

But everybody knows that! If you want, I hereby recognise that there
are two XSL Namespaces.

> 5. The confusing "indicative prefix" (my term) for those two
> namespaces should be corrected/made consistent. I would suggest that
> the XSLT namespace use the "indicative prefix" of "xslt" rather than
> "xsl" i.e. as an example, the present <xsl:stylesheet> element would
> become <xslt:stylesheet>. Similarly the "fo" indicative prefix would
> become "xslfo" i.e. <fo:root> would become <xslfo:root>.

The namespace prefix is something you decide when you write your XML
file. It can be 'xslt:', 'britneyspears:', you name it. And you can
write '<xslt:transform ...>' rather than '<xsl:stylesheet>' if you
want.

I agree that using xsl: in the text of the xslt spec is probably not
the best choice. You might want to re-submit that to xsl-editors (in a
shorter message).

> [ With regard to the more specific problem relating to the naming of
> the current XSL-FO CR could that not be called the "Extensible
> Stylesheet Language Formatting Objects, XSL-FO" Recommendation in
> due time?

no.

BTW, what's XSL-FO@egroups.com?

Max.
W3C XSLTFO working group.

Disposition: Explanation of why no change will be made

XSL is the umbrella name for the eXtensible Stylesheet Language that includes XSLT and XSL Formatting Objects. XSLT includes Xpath as the addressing and navigation mechanism. XSL Formatting Objects represent the set of typographic abstractions available to the designer. Sometimes people use these terms interchangeably. For example, XSL may be used to talk about XSLT only; this is inappropriate. To talk about XSL Formatting Objects people use the terms "XSL" and "XSL FO" interchangeably. We believe that this is where the confusion arises. For many reasons, we have not been able to develop an alternate nomenclature that works. We hope we have clarified the appropriate usage of the terms.

Andrew Watt

Comment 25 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0061.html

Date: Tue, 23 Jan 2001 11:09:28 -0500 (EST)
Message-ID: <3A6DACBA.515EEB59@powerup.com.au>
From: "Peter B. West" <pbwest@powerup.com.au>
To: xsl-editors@w3.org
Subject: [Fwd: Typo in 4.2.5 Stacking Constraints]

Forwarded on advice from Max Froumentin.

-------- Original Message --------
Subject: Typo in 4.2.5 Stacking Constraints
Date: Sun, 21 Jan 2001 17:57:38 +1000
From: "Peter B. West" <pbwest@powerup.com.au>
Reply-To: pbwest@powerup.com.au
Organization: Dis
To: fop-dev@xml.apache.org
References: <3A681DEA.18886.840F8E@localhost>
<3A6A8DBD.CF39F0F2@powerup.com.au>

Item 1

There is a small typo in the above section.  Compare b. and c.

b. B is the first normal child of a block-area, B is not a line-area, P,
there is no fence preceding P, A and P have a block-stacking constraint
S', and S  consists of S' followed by the space-before of B; or

c. A is the last normal child of a block-area P, A is not a line-area,
there is no fence following P, P and B have a block-stacking constraint
S'', and S  consists of the space-after of A followed by S''.

Disposition: Accepted (editorial)

The "P" in the first case has been moved to be after "block-area".

Links to the changed text in the XSL recommendation:

See link to changed text.

Peter
--
Peter B. West  pbwest@powerup.com.au
"Lord, to whom shall we go?"

Comment 26 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0062.html

Date: Tue, 23 Jan 2001 11:11:13 -0500 (EST)
Message-ID: <3A6DAD33.6FF2902B@powerup.com.au>
From: "Peter B. West" <pbwest@powerup.com.au>
To: xsl-editors@w3.org
Subject: [Fwd: Adjacent edges in 4.2.5 Stacking Constraints]



-------- Original Message --------
Subject: Adjacent edges in 4.2.5 Stacking Constraints
Date: Mon, 22 Jan 2001 22:47:12 +1000
From: "Peter B. West" <pbwest@powerup.com.au>
Reply-To: pbwest@powerup.com.au
Organization: Dis
To: fop-dev@xml.apache.org
References:
<3A681DEA.18886.840F8E@localhost><3A6A8DBD.CF39F0F2@powerup.com.au>
<3.0.6.32.20010121144340.007ff600@chebucto.ns.ca>

Item 1

A question about the definition of adjacent edges in 4.2.5.

The following definitions refer to the block-stacking-constraints.gif
image.  (Wouldn't it be useful to have numbered figures?  Wouldn't it be
useful to have an index?)

Adjacent Edges with Block-stacking
When A and B have a block-stacking constraint, the adjacent edges of A
and B are an ordered pair recursively defined as:
    * In case 1, the before-edge of the content-rectangle of A and the
before-edge of the allocation-rectangle of B.
    * In case 2, the after-edge of the content-rectangle of A and the
after-edge of the allocation-rectangle of B.

I don't have much of a grasp of this section, but shouldn't case 2 read:
    * In case 2, the after-edge of the allocation-rectangle of A and the
after-edge of the content-rectangle of B?

I.e., for contained areas, the appropriate relationship is between the
content-rectangle of the containing area, and the allocation-rectangle
of the contained area?

Disposition: Accepted (editorial)

Yes there is a typo in the spec.

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

Peter
--
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

Comment 27 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0063.html

Date: Tue, 23 Jan 2001 11:11:09 -0500 (EST)
Message-ID: <3A6DAD01.D99AE3FB@powerup.com.au>
From: "Peter B. West" <pbwest@powerup.com.au>
To: xsl-editors@w3.org
Subject: [Fwd: large-allocation-rectangle of inline-area]

Forwarded on advice from Max Froumentin.

-------- Original Message --------
Subject: large-allocation-rectangle of inline-area
Date: Sun, 21 Jan 2001 17:20:29 +1000
From: "Peter B. West" <pbwest@powerup.com.au>
Reply-To: pbwest@powerup.com.au
Organization: Dis
To: fop-dev@xml.apache.org
References: <3A681DEA.18886.840F8E@localhost>

Item 1

The diagram AllocationRectInline-large.gif which illustrates the
large-allocation-rectangle of an inline-area in 4.2.3 Geometric
Definitions, appears to contradict the text.  The text has:
 The large-allocation-rectangle is the border-rectangle.
The diagram puts this rectangle in black around Spaces, outside the
Border Rectangle.  In addition, in the distributed multi-file HTML set,
the diagram is incorrectly named, and does not appear in the text.  (I
think the "large" was capitalised in the  file name.)

Disposition: Accepted (clarification)

The figure is very unclear and has been replaced with one where arrows indicate for each label which rectangle is meant.

Links to the changed text in the XSL recommendation:

See link to changed text.

Peter
--
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

Comment 28 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0064.html

Date: Tue, 23 Jan 2001 11:12:06 -0500 (EST)
Message-ID: <3A6DAD51.8349EB0C@powerup.com.au>
From: "Peter B. West" <pbwest@powerup.com.au>
To: xsl-editors@w3.org
Subject: [Fwd: Block-stacking constraint example in 4.2.5]



-------- Original Message --------
Subject: Block-stacking constraint example in 4.2.5
Date: Mon, 22 Jan 2001 22:57:18 +1000
From: "Peter B. West" <pbwest@powerup.com.au>
Reply-To: pbwest@powerup.com.au
Organization: Dis
To: fop-dev@xml.apache.org
References:
<3A681DEA.18886.840F8E@localhost><3A6A8DBD.CF39F0F2@powerup.com.au>
<3.0.6.32.20010121144340.007ff600@chebucto.ns.ca>

Item 1

The tree node diagram at the beginning of the above example
(mantree.gif), I personally would prefer to see replaced by nested block
diagrams as are used (block-stacking-constraints.gif) to illustrate the
concept of block-stacking constraints.  I.e., block diagrams including
the stacking constraints, and also the fence-after B which eliminates
the D-E constraint.

Disposition: Explanation of why no change will be made

The idea behind this form of the diagram is to emphasize that this relationship is deducible from the tree structure and trait values, not the geometric proximity of the areas.

Peter
--
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

Comment 29 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0066.html

Date: Sat, 27 Jan 2001 07:13:42 -0500 (EST)
Message-ID: <3A72BB5B.12843B4C@powerup.com.au>
From: "Peter B. West" <pbwest@powerup.com.au>
To: fop-dev@xml.apache.org
CC: xsl-editors@w3.org
Subject: 5.3.2 Margin, Space, and Indent Properties

Item 1

The above section seems to define the relationship between, say,
end-indent and padding/border/space-end shown in the diagram
RectsForModel.gif in 4.4.1 Stacked Block-areas.  I.e., end-indent =
padding-end + border-end + space-end, where, according to 5.3.2,
space-end has a corresponding margin property.  5.3.2 has
end-indent = margin-corresponding + padding-end + border-end-width

What does this do to the following announcement in 4.4.1?

   1. For each block-area B which is a descendant of P, the following
hold
      ....
    * the end-edge of its allocation-rectangle is parallel to the
end-edge
      of the content-rectangle of R, and offset from it inward by a
      distance equal to the block-area's end-indent plus its
      end-intrusion-adjustment (as defined below), minus its border-end,
      padding-end, and space-end value

Isn't that saying, "...a distance equal to the block-area's end-indent
plus its end-intrusion-adjustment minus its end-indent"?  That's what
the diagram seemed to indicate when I first read 4.4.1, and now, having
just read 5.3.2 (I'm a slow reader of specifications) that initial
impression is confirmed.  What am I missing?

Disposition: Explanation of XSL spec

Section 5.3.2 has an error in that one should also add inherited-*-indent to obtain the *-indent from the *-margin. (Murakami pointed this out in a posting to the editor's list).

Indents are "absolute" i.e. with respect to the containing reference area. Margins are with respect to the "containing block" and as such an indent is equal to the sum of the ancestor blocks' margins.

Links to the changed text in the XSL recommendation:

See link to changed text.

Peter
--
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

Comment 30 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0067.html

Date: Sat, 27 Jan 2001 09:14:33 -0500 (EST)
Message-ID: <3A72D7D8.4ECB0A08@powerup.com.au>
From: "Peter B. West" <pbwest@powerup.com.au>
To: fop-dev@xml.apache.org
CC: xsl-editors@w3.org
Subject: 5.3.3 Height, and Width Properties

Item 1

The above section has a number of paragraphs like:

    * If any of "height", "min-height", or "max-height" is
specified:
          * If "height" is specified then first set:
            block-progression-dimension.minimum=<height>
            block-progression-dimension.optimum=<height>
            block-progression-dimension.maximum=<height>
          *
            If "height" is not specified, then first set:
            block-progression-dimension.minimum=auto
            block-progression-dimension.optimum=auto
            block-progression-dimension.maximum=auto
          *
            Then, if "min-height" is specified, reset:
            block-progression-dimension.minimum=<min-height>
          *
            Then, if "max-height" is specified, reset:
            block-progression-dimension.minimum=<max-height>

Shouldn't the last read:
Then, if "max-height" is specified, reset:
block-progression-dimension.MAXimum=<max-height>
?

There are four such instances.

Disposition: Accepted (bug in spec)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Peter
--
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

Comment 31 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0096.html

Message-ID: <3A8C62BE.7A5C29AC@club-internet.fr>
Date: Fri, 16 Feb 2001 00:14:06 +0100
From: Karen Lease <klease@club-internet.fr>
To: xsl-editors@w3.org
CC: fop-dev@xml.apache.org
Subject: Interaction of shorthand and corresponding properties

Dear editors,

Item 1

Could you one of you please comment on the following cases assuming the
block progression direction is top to bottom :

A <fo:block padding="3pt" padding-top="4pt">....

According to 5.2 and 5.3.1, I see the following property values being
set for padding-top and padding-before.

padding-before=0pt, padding-top=0pt (initial values)
padding-top=3pt (from the shorthand)
padding-top=4pt (set explicitly)
padding-before=4pt (set from the corresponding padding-top property)

Now supposing we have this:
B <fo:block padding="3pt" padding-before="4pt">....

This seems to imply the following values being set

padding-before=0pt, padding-top=0pt (initial values)
padding-top=3pt (from the shorthand)
padding-before=3pt (set from the corresponding padding-top property, so
the explicit setting of 4pt is ignored!)

What I (as a user) expect to happen is this:
padding-before=4pt (set explicitly)
padding-top=4pt (set from the corresponding padding-before property ???)


In 5.3.1, the CR says:
"If the corresponding absolute variant of the property is specified on
the formatting object, its computed value is used to set the computed
value of the
corresponding relative property. If the corresponding absolute property
is not
explicitly specified, then the computed value of the absolute property
is set to the computed value of the corresponding relative property."

This rule works fine for case A. In case B, it seems that I can only get
padding-before (and padding-top) set to 4pt if I consider that the
shorthand is not equivalent to setting the absolute property explicitly,
so that the explicit value of the relative property is used (for both).

But then what about this?
C <fo:block padding="3pt">....

This seems to imply the following values should be set:

padding-before=0pt, padding-top=0pt (initial values)
padding-top=3pt (from the shorthand)
padding-before=3pt (set from the corresponding padding-top property)

But here, I want to use the value set by the shorthand to set the
relative property.
In other words, the behavior that seems natural is that the shorthand
setting of the absolute property is "weaker" than the explicit setting
of the corresponding relative property. If that's what you meant,
perhaps you could make it clearer in the next (final?) version.

Disposition: Accepted (clarification)

Text to clarify that your last paragraph is indeed the intended meaning has been added.

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

Thanks in advance for your feedback,
Karen Lease (FOP contributer)



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Comment 32 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0097.html

Date: Thu, 15 Feb 2001 18:18:33 -0500 (EST)
Message-ID: <3A8C6559.17344CA4@club-internet.fr>
From: Karen Lease <klease@club-internet.fr>
To: xsl-editors@w3.org
CC: fop-dev@xml.apache.org
Subject: Meaning of keyword "inherit" for non-inheritable properties

Hello again,

Item 1

I suppose this has been mentioned before, but it still bothers me to be
able to specify xxx="inherit" when xxx isn't inheritable. (Of course, if
it is inheritable, there's no reason to say so, since if xxx isn't
specified, it will get the value from its parent.)

The meaning seems to be identical to xxx="from-parent(xxx)", including
the case of shorthand properties.

So is this just to simplify life for users?

Discussion message: lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0099.html

Message-Id: <4.2.0.58.J.20010218171618.03cec830@sh.w3.mag.keio.ac.jp>
Date: Sun, 18 Feb 2001 17:18:35 +0900
To: Karen Lease <klease@club-internet.fr>, xsl-editors@w3.org
From: Martin Duerst <duerst@w3.org>
Cc: fop-dev@xml.apache.org
Subject: Re: Meaning of keyword "inherit" for non-inheritable properties

At 18:18 01/02/15 -0500, Karen Lease wrote:
>Hello again,
>
>I suppose this has been mentioned before, but it still bothers me to be
>able to specify xxx="inherit" when xxx isn't inheritable.

Please change 'inheritable' to 'inherited', and everything
looks much more reasonable (I'm not sure where you got the
word 'inheritable' from, I hope it's not in the spec itself.)

Either a property is (by default) inherited, or it can be
inherited by specifying 'inherit' as a property value.

Regards,   Martin.



>(Of course, if
>it is inheritable, there's no reason to say so, since if xxx isn't
>specified, it will get the value from its parent.)
>
>The meaning seems to be identical to xxx="from-parent(xxx)", including
>the case of shorthand properties.
>
>So is this just to simplify life for users?
>
>Karen Lease (FOP contributor)

Discussion message: lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0107.html

To: Karen Lease <klease@club-internet.fr>
Cc: xsl-editors@w3.org
From: Max Froumentin <mf@w3.org>
Date: 20 Feb 2001 13:37:21 +0100
Message-ID: <yq8elwtv8ce.fsf@jfouffa.inria.fr>
Subject: Re: Meaning of keyword "inherit" for non-inheritable properties

Karen Lease <klease@club-internet.fr> writes:

> I suppose this has been mentioned before, but it still bothers me to be
> able to specify xxx="inherit" when xxx isn't inheritable.

I guess one should read 'Inherited by default: none' where the spec
says 'Inherited: no'.

> (Of course, if it is inheritable, there's no reason to say so, since
> if xxx isn't specified, it will get the value from its parent.)

In CSS, it makes sense to specify 'inherit' as a value even though the
property is inheritable because the value may have been set to
something else in the cascading process and you want to override it.

In XSL it also makes sense, but for shorthand properties. For example
you might have (probably as the result of the expansion of a
use-attribute-set): font="bold 12pt helvetica" font-size="inherited".
font-size is inherited by default but you still have to specify it to
override the shorthand property.

Does this answer your question?

Max.

Disposition: Explanation of why no change will be made

The "inherit" keyword, as well as the term "inheritable", are both used in CSS2 and for compatibility reasons are used in XSL as well (even if "copy from parent" would have been more natural).

Karen Lease (FOP contributor)

Comment 33 (W3C staff editorial review): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0109.html

Message-Id: <p05010404b6ba642a6c1b@[204.210.33.45]>
Date: Wed, 21 Feb 2001 22:40:56 -0800
To: xsl-editors@w3.org
From: Susan Lesch <lesch@w3.org>
Subject: Comments for CR-xsl-20001121

These are comments for your XSL 1.0 Candidate Recommendation [1] "work in
progress," based on one reading. It is a beautiful piece of work. Most
likely I missed a few things, and hope to read this again when/if it
reaches Proposed Recommendation.

General
-------

Item 1

There appears to be a glitch in a production script or DTD that is adding
unneeded table markup in the form of default and empty HTML attribute values.
For example, there are over 5000 occurrences of "rowspan="1" colspan="1"
align="left"." Removing extraneous table markup will cut the HTML version
by 15%, from 1.5 down to 1.2MB (more than 25% for section 7 alone).

Disposition: Accepted (editorial)

Item 2

Chapter 2, Introduction to XSL Transformation, has little to do with XSLT
and a lot about Namespaces in XML. Should this chapter have a new title?

Disposition: Accepted (editorial)

The title has been changed to "XSL Transformation", which is a more appropriate title and does more naturally contain namespace information pertinent to xsl transformation usage.

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 3

I would save 10k and omit 6.3 Formatting Objects Summary, since this
information is repeated on the same page.

Disposition: Explanation of why no change will be made

6.3 provides a short summary for each formatting object to aid the reader in finding which object he may be searching for; the WG feels it a useful navigation aid.

Item 4

In the 7.2 table, the top row should be th elements to meet level-A Web
Content Accessibility Guidelines; (see checkpoint 5.1 on
http://www.w3.org/TR/WAI-WEBCONTENT/#gl-table-markup).
<th>Box</th><th>Area</th>

Disposition: Accepted (editorial)

Item 5

Colors as well as border widths would help to differentiate the three kinds
of property descriptions in section 7. (I'm not certain that they need to
be differentiated at all since they are labeled, but was mildly confused by
the presence and absence of two different yet similar black borders.)

Disposition: Accepted (editorial)

The border has been changed to be black for CSS2 properties, and gray for CSS2 derived properties.

Globally
--------

Item 6

Reserved words like fo and property names, datatype names, units and
boolean values are sometimes plain text, sometimes in double quotes,
sometimes in single quotes, sometimes in angle brackets, sometimes bold,
and once in a while monospace. (Some of these treatments come from CSS2.)
It's a big job to change them all, but it would help the reader if you
could establish and stick to a pattern.

Disposition: Explanation of why no change will be made

We agree that it would be nice if the quotation and font weight was consistent, but in addition to changes in the XSL text it would require changes to quoted CSS2 text as well.

Item 7

"White space" is two words. DSSSL has it as one word, and Merriam-Webster,
American Heritage, and XML give it as two. (See
http://www.w3.org/TR/REC-xml#sec-white-space.) "Word space" and "letter
space" are two words also, and not hyphenated.

Disposition: Accepted (editorial)

The convention for text, except for text quoted from CSS2, has been changed to "white space", "word space", "letter space". For property names and values hyphens are used to separate the parts.

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Item 8

Globally and in particular in 7.14.7 "linefeed-treatment", line feed is two
words; (see http://www.unicode.org/charts/PDF/U0000.pdf). Maybe this
property should be named line-feed-treatment. Also, in 7.14.8,
ignore-if-before-linefeed -> ignore-if-before-line-feed, etc.

Disposition: Explanation of why no change will be made

The WG feels that linefeed as one word is better in the property name.

Item 9

As far as I know, user agent is not a proper noun. Throughout the spec, it
is most often capitalized, sometimes not. It could be lowercase always, or
always one way or the other.

Disposition: Explanation of why no change will be made

We tried to match CSS "cap U cap A". CSS is, however, inconsistent and we cannot change it there.

Item 10

When referring to a W3C Recommendation, "Recommendation" is capitalized
(following Process Document usage, see
http://www.w3.org/Consortium/Process/).

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Item 11

Mentions of the Unicode bidirectional algorithm need to be uniform. Maybe
these notes will help. Unicode is capitalized and the other two words are
not. UAX#9 has two occurrences of "BIDI" and none for "bidi." So, for its
first occurrence, say
     Unicode bidirectional (BIDI) algorithm
and then
     Unicode BIDI algorithm
or else spell out the whole name each time.

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Images
------

Item 12

If there is time, could all the images match? For example in section 4 they
look like the work of a few different people.

Disposition: Explanation of why no change will be made

For practical reasons the graphics have indeed been created by several people using different tools.

It would be very nice if the W3C, in addition to supplying excellent editorial review support, also offered a drawing service to ensure that the illustrations in all W3C Recommendations were of uniform style.

Item 13

In sections 1, 4, 6 and 7, all images need alt text and real rather than
GIF text so that people who cannot see the illustrations can follow.
Section 7 looks good and may need only minor changes. Here's one way, for
section 1.
<div class="image">
<p class="caption">XSL Two Processes: Transformation and Formatting</p>
<p><img src="two-process.gif" alt="Diagram of XSL conceptual model, showing
a source tree, a result tree with element and attribute nodes, and XSL
formatters including a printer, a cell phone, and a Web browser."></p>
<p class="explanation">The result tree is the result of XSLT processing.</p>
</div>

Disposition: Accepted (editorial)

Alt text has been added to all the graphics.

Item 14

In 4.10, in the sample area tree image, letter spacing is off and some text
is covered. Could this image (page-area-tree.gif) be fixed? Some labels in
japaneseblock3.gif in section 4.2.3 also have minor letter spacing
problems. In 6.4.1.6, the top of the top "f" and the right side of the
right-hand "w" are missing.

Disposition: Accepted (editorial)

These "problems" are due to rasterization difficulties in the graphics packages used to create a gif image of a size that would fit into a normal browser window. For detailed studies of the graphics the PDF version of the Recommendation should be used, as these graphics can be made at a higher resolution.

page-area-tree and PageTree have been replaced by gif files rasterized using a different graphics package and this has made some improvements.

Item 15

In 6.4.12, the vertical labels are unreadable in the peach colored part of
PageAndRegion-bodyWithOrientationOnPage.gif (third image). Otherwise, this
is a really nice diagram.

Disposition: Accepted (editorial)

The size of the text has been increased, while keeping the graphic at its current size to fit in a typical browser window.

References
----------

Item 16

You might alphabetize references.

Disposition: Explanation of why no change will be made

The references are grouped by topic, which the WG feels is more appropriate than alphabetical.

Item 17

In "W3C XML," "W3C XML Names," and "W3C XML Stylesheet," why say "W3C" in
the short name of some and not all W3C references? W3C can be omitted.

Disposition: Accepted (editorial)

W3C has been omitted in the short name.

Item 18

In D.1, XML 1.0 is of course now in its second edition, and "See
http://www.w3.org/TR/1998/REC-xml-19980210" can read "See
http://www.w3.org/TR/2000/REC-xml-20001006".

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 19

In D.2 W3C XML Stylesheet
     W3C Working Draft. See http://www.w3.org/TR/WD-xml-stylesheet
becomes:
     W3C Recommendation. See http://www.w3.org/TR/xml-stylesheet/

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 20

In D.1, the citation would be:
     Unicode Standard Annex #9: The Bidirectional Algorithm
(see http://www.unicode.org/unicode/standard/versions/)

Disposition: Accepted (editorial)

The reference has been changed to conform to the reference format given in http://www.unicode.org/unicode/standard/versions/.

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 21

In D.2, UNICODE TR10 is Unicode Technical Standard #10 (a UTS rather than
UTR and no longer a draft).

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 22

In D.2, UNICODE TR20 is Unicode Technical Report #20 (no longer a draft).

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 23

Also for the three Unicode references, index.html can be cut from the URI.

Disposition: Accepted (editorial)

Item 24

For 7.8.1, 7.8.2, 7.28.24, and D.1, the reference can be RFC 3066; (RFC
1766 is obsolete). See http://www.ietf.org/rfc/rfc3066.txt.

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Item 25

RFC 2119 can be a normative reference, and section 8 could say:
       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
       "OPTIONAL" in this document are to be interpreted as described in
       [RFC2119].
Please see RFC 2119 at http://www.ietf.org/rfc/rfc2119.txt. If you don't
want to use the RFC, those words need definitions if used in section 8.

Disposition: Accepted (editorial)

Text has been added to section 8 to state that the words in the section are used in accordance with RFC 2119.

Links to the changed text in the XSL recommendation:

See link to changed text.

Minor typos
-----------
 From here down, a section number is followed by a quote and then a
suggestion.

Item 26

Authors and Contributors
ArborText
Arbortext

Disposition: Accepted (editorial)

Item 27

Status of this document
encourges
encourages

Disposition: Accepted (editorial)

Item 28

1.2.1
XPath (first occurrence)
<a href="sliceD.html#XPATH">[XPath]</a>

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 29

1.2.1 par. 5
line-feeds
line feeds

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 30

1.2.5 last par. (they are dictionary words)
used for sub- and super-scripts
used for sub- and superscripts

Disposition: Accepted (editorial)

The full form has been used for both (to make it easier for non-native English speakers).

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Item 31

4.2.2 last list item needs closing parenthesis.

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 32

5.2 Note (first occurrence of conformance) and 7.28 par. 1
     Shorthands are only included in the highest XSL conformance
     level: "complete".
could link to <a href="slice8.html">[8. Conformance]</a>

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

Item 33

5.8 par. 2
based on both of an implicit part
based on both an implicit part

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 34

5.8 par. 4
UNICODE TR-9
Unicode Standard Annex #9 or UAX#9 or [UNICODE TR9] (not sure which is best
but I don't think it's hyphenated)

Disposition: Accepted (editorial)

Replaced with a bibliography reference.

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 35

5.8 last Note
spliting
splitting

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 36

5.9.6 last par.
value of property
value of a property

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 37

5.9.7 needs an ending period.

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 38

5.9.9 (link needed at first occurrence)
Only RGB (Red, Green, Blue) and ICC (International Color Consortium)
Only RGB (Red, Green, Blue) [sRGB] and ICC (International Color
Consortium) [ICC]
(adding a new reference, http://www.w3.org/Graphics/Color/sRGB.html)

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

Item 39

5.11 <uri-specification>
URI-reference
URI reference

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 40

6.3 bidi-override
Unicode-bidirectionality algorithm direction
Unicode-bidirectional-algorithm direction

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 41

6.4.4 par. 3
function[5.10.2 Color Functions]
function [5.10.2 Color Functions]

Disposition: Accepted (editorial)

Item 42

6.4.4 list item 2
sRGB
Needs a link to references [sRGB].

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 43

6.4.7 Constraints
Note that the mapping of sub-sequences of the sequence
of pages to sub-sequence-specifiers need not be onto;
                                                  ^
(I wasn't sure if "onto" meant one to one.)

Disposition: Accepted (editorial)

The intention is "onto". The text has, however, been changed to make the reading easier.

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 44

6.4.10 Constraints
the sub-sequence of pages consist
the sub-sequence of pages consists

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 45

6.4.19 Constraints
if P is a page-reference-area C is an area-class, and
if P is a page-reference-area, C is an area-class, and

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 46

6.5.2 Note after Trait Derivation:
uasge
usage

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 47

6.6.3 par. 4
Unicode Special-use tag characters
Unicode special-use tag characters
(see http://www.unicode.org/unicode/reports/tr7/index.html)

Disposition: Accepted (editorial)

Unicode 3.1 calls these "Tag Characters" and the text is included in the Standard obsoleting TR 7. The sentence and note have been reworded to take this into account.

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

Item 48

6.6.3 Constraints
The dimensions of the area is
The dimensions of the area are

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 49

6.6.5 last Note
For example, using a size of 1/96" as the size of one pixel for rasterized
images. is an incomplete sentence.

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 50

6.6.7 Contents
a descendant an fo:leader
a descendant of an fo:leader

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 51

6.7.1.1.1 par. 1
specificed
specified

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 52

6.10.3 Constraints par. 3
fo:foonote
fo:footnote

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 53

6.11.1.1
the "code" elements are using a Courier font
the "code" elements using a Courier font

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 54

7.3.1 second to last par.
W3C Accessibility guidelines
W3C accessibility guidelines (which ones? Can you link to them?)

Disposition: Accepted (editorial)

What is meant is the collection of guidelines developed by the W3C WAI Initiative. Links have been added in the text.

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 55

7.3.2
An URI-specification
A URI-specification

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 56

7.3.2 second to last par.
(QName [W3C XML Names]
Needs a closing parenthesis.

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 57

7.7.1 par. 8
Far-Eastern (twice)
Far Eastern
(not sure eastern and western have global meaning either)

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

Item 58

7.7.1 caption for second illustration
EM Box
EM box

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

Item 59

Example 4
example 4

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 60

7.7.4 last par.
rounded the nearest whole pixel
rounded to the nearest whole pixel

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 61

7.7.7 backslant and 7.7.8 second to last par.
(http://www.w3.org/TR/REC-CSS2/fonts.html#algorithm")
(http://www.w3.org/TR/REC-CSS2/fonts.html#algorithm)

Disposition: Accepted (editorial)

Item 62

7.12 par. before last illustration
super-script (or sub-script)
superscript (or subscript)

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Item 63

In 7.20.4, ending double quote can be cut.

Disposition: Accepted (editorial)

Item 64

7.21.2 Note
sub-title
subtitle (It's a dictionary word. Not sure that is what is meant.)

Disposition: Accepted (editorial)

Yes it is meant to be "subordinate" titles.

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 65

7.24.8 media:
viaual
visual

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 66

7.24.10 bounded-in-one-dimension second par. can have an ordered list:

...There are four cases:

     1. the "reference-orientation" is "0" or "180" and the
       "writing-mode" is horizontal;
     2. the "reference-orientation" is "0" or "180" and the
       "writing-mode" is vertical;
     3. the "reference-orientation" is "90" or "270" and the
       "writing-mode" is horizontal;
     4. the "reference-orientation" is "90" or "270" and the
       "writing-mode" is vertical.

For cases 1 and 3, the "page-width" is bounded and the "page-height" is not
bounded. For case 2 and 4, the "page-height" is bounded and the
"page-width" is not bounded....

Disposition: Explanation of why no change will be made

There seems to be little gain in presenting the information in a list form and for a typical browser/page size it risks taking up more space and XSL is long as it is...

Item 67

7.24.12 and 7.24.14 auto:
continous
continuous

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

Item 68

A fallback to 11.0in would fit on both 8+1/2x11 and A4 pages).
A fallback to 11in would fit on both 8 1/2 x 11 and A4 pages.
(not sure there)

Disposition: Accepted (editorial)

Changed to "11.0in would fit on both Letter size (8.5in by 11.0in) and A4 size pages.".

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 69

7.26 Note list item 2
Table
table

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 70

7.26.4 use-font-metrics
dominat
dominant

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 71

7.26.5 <length>
domiant
dominant

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 72

7.26.7
please see the "Internationalization Appendix".
please see <a href="sliceA.html">[A Internationalization]</a>.

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 73

7.28.13
"smallcaption"
small-caption or small caption

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 74

In B.7, there's an extra period after the aural fallback.

Disposition: Accepted (editorial)

Item 75

C.1 Refine
Refinement
refinement

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

[1] http://www.w3.org/TR/2000/CR-xsl-20001121/

Best wishes for your project,

--
Susan Lesch - mailto:lesch@w3.org  tel:+1.858.483.4819
World Wide Web Consortium (W3C) - http://www.w3.org/

Comment 34 (XSL WG comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0126.html

From: Tony Graham - Sun Ireland - Staff Engineer <Tony.Graham@ireland.sun.com>
Message-ID: <15015.37303.193881.935018@gargle.gargle.HOWL>
Date: Thu, 8 Mar 2001 14:05:43 +0000 (GMT)
To: xsl-editors@w3.org
Subject: W3C XML Stylesheet in CR-xsl-20001121

Item 1

The non-normative reference [W3C XML Stylesheet] in CR-xsl-20001121
refers to the working draft of what is now a W3C Recommendation.  The
URL for the Recommendation is http://www.w3.org/TR/xml-stylesheet/.

Disposition: Accepted (editorial)

The reference has been updated.

Regards,


Tony Graham
------------------------------------------------------------------------
Tony Graham                           mailto:tony.graham@ireland.sun.com
Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3            x(70)19708

Comment 35 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001AprJun/0000.html

Date: Sat, 31 Mar 2001 00:20:08 -0500 (EST)
Message-ID: <3AC5593A.8C0FF1C6@powerup.com.au>
From: "Peter B. West" <pbwest@powerup.com.au>
To: xsl-editors <xsl-editors@w3.org>
CC: fop-dev <fop-dev@xml.apache.org>
Subject: Ambiguities in XSL 1.0 spec

Item 1

6.4.14 fo:region-before

Areas:

The inline-progression-dimension of the region-viewport-area is
determined by the precedence trait on the fo:region-before. If the
value of the precedence trait is true, then the
inline-progression-dimension extends up to the
**start- and after-edges**
of the content-rectangle of the page-reference-area. In this case, the
region-before region-viewport-area acts like a float into areas
generated by the region-start and region-end.

Should `start- and after-edges' be `start- and end-edges'?

Likewise for 6.4.15 fo:region-after.

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

7.12 Area Alignment Properties

Item 2

Diagram Baselines-rev.gif

Note position of text-before-edge and text-after-edge.  Discussion in
NOTE to text-before-edge for ideographic scripts seems to contradict
the diagram.

'For ideographic fonts, the position of this baseline is normally 1 EM
in the shift-direction from the "ideographic" baseline.'

In the diagram, possibly due to the presence of non-ideographic fonts,
the text-before-edge seems to be 1 EM in the shift-direction from the
text-after-edge, and inside the EM box which is based on the ideographic
baseline.

Disposition: Explanation of XSL spec

The "text-before-edge" and "text-after-edge" shown in the figure is, as is stated in the text, computed under the assumption that it is the "alphabetic" baseline that is the dominant-baseline. IF the assumption had been instead that it was the "ideographic" baseline then the edge would have been as you describe.

Item 3

The first NOTE to the discussion of after-edge is unclear.

'If all the inline-areas in a line-area are aligned to the "after-edge"
then the specification for the "before-edge" will set the "before-edge"
baseline to coincide with the "text-before-baseline" of the line. Then,
case (2) above will determine an offset to the "bottom-edge" baseline
that will align the "before-edge" of the area with the greatest height
to its allocation-rectangle to "before-edge" baseline.'

Perhaps something along the lines of:
'Then, case (2) above will determine the offset to  the "bottom-edge"
baseline so as to fit the area with the tallest allocation-rectangle (in
the block-progression direction.)  When the "after-edge" of that tallest
area is aligned to the "after-edge" baseline, the "before-edge" of the
area coincides with the "before-edge" baseline.'

Disposition: Accepted (editorial)

The sentence has been rewritten, but the formulation suggested by the commentator cannot be used verbatim as it mixes absolute-direction terms like "bottom" and "tallest" with the relative designations of "before-edge" and "after-edge".

Links to the changed text in the XSL recommendation:

See link to changed text.

Peter
--
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

Comment 36 (XSL WG comment): lists.w3.org/Archives/Public/xsl-editors/2001AprJun/0008.html

From: Tony Graham - Sun Ireland - Staff Engineer <Tony.Graham@ireland.sun.com>
Message-ID: <15069.24449.973975.186838@gargle.gargle.HOWL>
Date: Wed, 18 Apr 2001 10:33:53 +0100 (BST)
To: xsl-editors@w3.org
Subject: Minor typo in abs() description in XSL CR

Item 1

The description of abs() in Section 5.10.1 begins:

   The abs functions returns...

"functions" should be "function".

Disposition: Accepted (editorial)

Item 2

The description of system-font() in Section 5.10.3 has the same
problem.

Disposition: Accepted (editorial)

Regards,


Tony Graham
------------------------------------------------------------------------
Tony Graham                           mailto:tony.graham@ireland.sun.com
Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3            x(70)19708

Comment 37 (XSL WG comment): lists.w3.org/Archives/Public/xsl-editors/2001AprJun/0009.html

From: Tony Graham - Sun Ireland - Staff Engineer <Tony.Graham@ireland.sun.com>
Message-ID: <15069.34479.174156.202345@gargle.gargle.HOWL>
Date: Wed, 18 Apr 2001 13:21:03 +0100 (BST)
To: xsl-editors@w3.org
Subject: "min" in definition of max() in XSL CR

Item 1

The definition of max() in Section 5.10.1 begins:

   The min function returns...

"min" should be "max".

Disposition: Accepted (editorial)

Regards,


Tony Graham
------------------------------------------------------------------------
Tony Graham                           mailto:tony.graham@ireland.sun.com
Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3            x(70)19708

Comment 38 (XSL WG comment):



Item 1

The list definitions of of "primitive" datatypes in section 5.11
is not complete.

Disposition: Accepted (editorial)

Definitions for <time> and <frequency> have been added.

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

Item 2

Composite properties: it is not clearly stated what a specification
of only one component of an inherited property means.

Disposition: Accepted (clarification)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 3

The name of the "icc color" function is the same in SVG
and XSL, but the arguments are different. This appears
undesirable.

Disposition: Accepted (clarification)

The xsl "icc-color" function has been renamed "rgb-icc".

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Item 4

Demanding the implementation of all three linestacking strategies
for basic conformance is too onerous and prevents the use of
many existing formaters with XSL.

Disposition: Accepted (bug in spec)

The basic conformance requirement has been relaxed.

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Item 5

The semantics of omitting the, optional, NCName, in
from-nearest-specified-value, from-table-column, merge-property-values
functions is not defined. Also in the inherited-property-value, and
from-parent functions should have the NCName optional for consistency.

Disposition: Accepted (bug in spec)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Item 6

Tables: for collapsing borders it is not specified where
the border is placed on a pixel device in the case of a border
thickness of an uneven number of pixels.

Disposition: Accepted (editorial)

Text to the effect that it is implmenentation defined has been added.

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 7

It shold be clarified that table cells may not overlap
geometrically.

Disposition: Accepted (clarification)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 8



Disposition: Accepted (editorial)

The text-altitude and text-depth labels are reversed in the figure showing "Nominal and Maximum Line Rectangles".

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 9

The specification of "side floats" need to be revised and be
more precise.

Disposition: Accepted (bug in spec)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Item 10

Alignment baselines need some review and clarification.

Disposition: Accepted (clarification)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Item 11

In CSS2 spaced around "empty" blocks and inlines merge with
the spaces before and after the "empty" area. XSL should do the
same for compatibility.
The text for merging spaces could be made clearer.

Disposition: Accepted (bug in spec)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

See link to changed text.

Item 12

The text for the constraints on block-progression-dimension
should be clarified and it should be made clear that block-areas
are properly stacked, unless the FO description states otherwise.

Disposition: Accepted (editorial)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

Item 13

The block-progression-dimension of the area generated by an
fo:list-item should be clarified.

Disposition: Accepted (clarification)

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 14

There appears to be a typo in the error recovery for a
"bounded-in-one-direction value; should it not be "(1) and (4)"
and "(2) and (3)"?

Disposition: Accepted (editorial)

Yes.

Links to the changed text in the XSL recommendation:

See link to changed text.

Item 15

The first and last line needs to be defined more rigorously
for "last-line-end-indent", "text-aling-last", and
"text-align".

Disposition: Accepted (clarification)

Links to the changed text in the XSL recommendation:

See link to changed text.

See link to changed text.

See link to changed text.

Item 16

The description of "left" needs to refer to "overconstrained"
geometry for certain non-"auto" values of properties.

Disposition: Accepted (clarification)

Links to the changed text in the XSL recommendation:

See link to changed text.



Comment 39 (Public comment)

http://lists.w3.org/Archives/Public/xsl-editors/2001JulSep/0035.html

From: "Glenn Adams" <glenn@xfsi.com>
To: <xsl-editors@w3.org>
Date: Mon, 30 Jul 2001 12:49:55 -0400
Subject: RE: table-cell border precedence

table-cell border precedenceI have pointed out these and other
inconsistencies already. My primary concern at this point is that the XSL FO
group has apparently punted on supporting the CSS2 semantics for collapsing
borders which they normatively reference. In particular, the XSL FO group
apparently believes that the border precedence can be computed on cells
during XSLT processing. However, I have shown definitively that this is
impossible to do when the border widths are based on relative units that can
only be computed during the formatting process.

I have urged that a simple solution be added to resolve this problem;
namely, than an "auto" value be added for the border precedence properties
which would have a meaning of "determine precedence base on CSS2 algorithm".

So far, however, the XSL FO group seems to have ignored my suggestion.

Discussion Message

From: Bert Bos <bert@w3.org>
Subject: RE: table-cell border precedence

It seems Glenn has a point: you cannot always get the same rendering
from XSL-FO tables as from CSS2 tables. The expression language in
XSL-FO isn't powerful enough to express the precedence rules of CSS2.

I'm trying to understand in what situation CSS2 behaviour cannot be
simulated with explicit precedences in XSL-FO. One such situation
appears to be as follows (in HTML + CSS):

    <table>
<tr style="border: 2px solid">
<td style="border: 0.1em solid">
...

The effect is that there will be a border of 2px, unless the cell has
a font that is bigger than 20px. In XSL, that would be something like:

    <fo:table...>
<fo:table-row border="2px solid">
<fo:table-cell border="0.1em solid" border-precedence="XXX">
...

Where the XXX is an expression that yields a large number when 0.1em
is greater than 2px and a small number otherwise. Unfortunately, this
doesn't work:

*   <choose>
<when test="0.1em > 2px">1000</when>
<otherwise>-1000</otherwise>
</choose>

since XSLT doesn't know about lengths. The expressions in XSL-FO
itself don't seem to allow comparisons, and they don't have
conversions from lengths to numbers either.

*   0.1em > 2px ? 1000 : -1000

So it seems that an expression will not work.

The question then is, whether the designer himself always knows the
font size and can choose the right precedence. In many cases he
probably knows, but not if he imports a style sheet from elsewhere, or
writes a reusable library of style sheet fragments.

Glenn's suggestion of allowing border-precedence="auto" has some
problems, too. What happens if some border-precedence attributes are
"auto" and some others are not? Maybe it is easier to add a value
"collapse-explicit-precedence" to border-collapse:

    collapse | separate | collapse-explicit-precedence | inherit

in which case "collapse" would mean the same as in CSS2, and
"collapse-explicit-precedence" would use the border-precedence
attributes.

Bert

Discussion Message

From: Steve Zilles <szilles@adobe.com>
Subject: PLEASE READ: Border-collapse property (again)

Bert Bos has just responded to an email of Glenn Adams where Bert notes that Glenn's proposed "auto" value will not work.

Separately, Murakami-san has also raised some concerns about the lack of 
direct support for the CSS2 border conflict resolution rule.

Bert makes what seems to me (and to Sharon Adler) to be a constructive way 
around this problem. We agreed that we need precedence values to be able to 
match table border models other than that of CSS. But, we need the CSS 
implicit rules also because there is no way to match, exactly, the CSS 
rules using just precedence. Therefore, Bert suggests having an additional 
value for the "border-collapse" property.

This suggests the following value syntax (a slight modification of Bert's 
proposal):

     collapse | separate | collapse-with-precedence | inherit

With this syntax, "collapse" and "separate" would have the meaning they 
currently have in CSS and "collapse-with-precedence" would have the meaning 
that was added in XSL.

Note that in CSS the values "collapse" and "separate" just mean use the 
collapsing borders model or use the separate borders model, respectively. 
There are separate sections of the CSS document that define these models.

In XSL, currently, there is no separate section that defines the models, 
instead, the description of the fo:table-cell FO has the semantics for 
these values. In XSL, the semantics of "separate" is the same as for CSS. 
The XSL semantics for the "collapse" value (the XSL borders model) is 
different from CSS. What the above proposal does is (a) associate the 
semantics of the XSL borders model with the value 
"collapse-with-precedence" and (b) requires adding the semantics of the CSS 
collapsing borders model, associated with the "collapse" value, to the 
fo:table-cell FO description.

In more concrete terms, it would be necessary (a) modify the text of the 
XSL PR that is currently associated the "collapse" value to instead be 
associated with the "collapse-with-precedence" value and (b) to add text 
for the "collapse" value. These modifications would be to the FO's (some 
table related FO's) to which the "border-collapse" property applies.

For all but fo:table-cell, the current text is of the form:

[7.7 Common Border, Padding, and Background Properties]
NOTE:
Only the background properties from this set apply. If the value of 
border-collapse is "collapse" for the table the border properties also apply.

which should become

[7.7 Common Border, Padding, and Background Properties]
NOTE:
If the value of border-collapse is "collapse", all the properties apply. If 
the value of border-collapse is "separate" or "collapse-with-precedence, 
only the background properties from this set apply. If the value of 
border-collapse is "collapse-with-precedence" for the table the border 
properties also apply.

For fo:table and fo:table-cell, the current text is of the form:
Trait Derivation:
[...]
If the value of the border-collapse trait is "collapse" the border for each 
side of the cell is determined by, for each segment of a border, selecting, 
from all border specifications for that segment, the border that has the 
highest precedence. It is an error if there are two such borders that have 
the same precedence but are not identical. Each border segment is placed 
centered on the table grid boundary line. On devices that do not support 
sub-pixel rendering, if an effective border width is determined to be an 
odd number of pixels it is implementation defined on which side of the grid 
boundry line the odd pixel is placed.

Constraints:
A table-cell occupies one or more grid units in the 
row-progression-direction and column-progression-direction. The 
content-rectangle of the cell is the size of the portion of the grid the 
cell occupies minus, for each of the four sides:
·       If the value of the border-collapse trait is "separate": half the 
value of the border-separation trait; otherwise 0.
·       If the value of the border-collapse trait is "separate": the 
thickness of the cell-border; otherwise half the thickness of the effective 
border.

This becomes:
Trait Derivation:
[...]
If the value of the border-collapse trait is "collapse-with-precedence" the 
border for each side of the cell is determined by, for each segment of a 
border, selecting, from all border specifications for that segment, the 
border that has the highest precedence. It is an error if there are two 
such borders that have the same precedence but are not identical. Each 
border segment is placed centered on the table grid boundary line. On 
devices that do not support sub-pixel rendering, if an effective border 
width is determined to be an odd number of pixels it is implementation 
defined on which side of the grid boundary line the odd pixel is placed.

If the value of the border-collapse trait is "collapse", the border for 
each side of the cell is determined by, for each segment of a border, 
selecting, from all border specifications for that segment, the border that 
has the most "eye catching" border style, see below for the details. Each 
border segment is placed centered on the table grid boundary line. On 
devices that do not support sub-pixel rendering, if an effective border 
width is determined to be an odd number of pixels it is implementation 
defined on which side of the grid boundary line the odd pixel is placed. 
Where there is a conflict between the styles of border segments that 
collapse, the following rules determine which border style "wins":
1. Borders with the 'border-style' of 'hidden' take precedence over all 
other conflicting borders. Any border with this value suppresses all 
borders at this location.
2. Borders with a style of 'none' have the lowest priority. Only if the 
border properties of all the elements meeting at this edge are 'none' will 
the border be omitted (but note that 'none' is the default value for the 
border style.)
3. If none of the styles is 'hidden' and at least one of them is not 
'none', then narrow borders are discarded in favor of wider ones.
4. If the remaining border styles have the same 'border-width' than styles 
are preferred in this order: 'double', 'solid', 'dashed', 'dotted', 
'ridge', 'outset', 'groove', and the lowest: 'inset'.
5. If border styles differ only in color, then a style set on a cell wins 
over one on a row, which wins over a row group, column, column group and, 
lastly, table.

(Note that no change is needed to the following section because the 
exceptional case is  the "separate" case and the two forms of "collapsing" 
have identical constraints; just different precedence rules.)
Constraints:
A table-cell occupies one or more grid units in the 
row-progression-direction and column-progression-direction. The 
content-rectangle of the cell is the size of the portion of the grid the 
cell occupies minus, for each of the four sides:
·       If the value of the border-collapse trait is "separate": half the 
value of the border-separation trait; otherwise 0.
·       If the value of the border-collapse trait is "separate": the 
thickness of the cell-border; otherwise half the thickness of the effective 
border.

Discussion Message

From: "Glenn Adams" <glenn@xfsi.com>
Date: Fri, 17 Aug 2001 20:35:13 -0400
MSubject: RE: PLEASE READ: Border-collapse property (again)

If the suggested change is made, then I withdraw my minority position objection.
I agree that Bert's proposal addresses my concerns; however, I 
would also note that it would be possible to use the "auto" value for precedence
without introducing a new value for "border-collapse" if prioritiy rules were 
established to distinguish between the precedence of "auto" and explicit numeric 
precedences. Nevertheless, I think Bert's proposal is preferable as the mixture 
of these two precedence models is not well established in practice whereas the
two distinct models (collapse and collapse-with-precedence) are better 
established in practice in isolation.
 

Disposition: Accepted (bug in spec)

Link to the changed text in the XSL recommendation:

See link to changed text.


Summary

Comment 1 (XSL WG comment):

Item 1: Accepted (editorial)


Comment 2 (XSL WG comment):

Item 1: Accepted (bug in spec)


Comment 3 (XSL WG comment):

Item 1: Explanation of XSL spec

Item 2: Explanation of XSL spec

Item 3: Explanation of XSL spec


Comment 4 (public comment):

Item 1: Accepted (clarification)


Comment 5 (public comment):

Item 1: Accepted (editorial)

Item 2: Accepted (editorial)


Comment 6 (public comment):

Item 1: Accepted (editorial)

Item 2: Accepted (editorial)


Comment 7 (public comment):

Item 1: Accepted (editorial)


Comment 8 (public comment):

Item 1: Accepted (clarification)

Item 2: Accepted (editorial)


Comment 9 (public comment):

Item 1: Explanation of why no change will be made


Comment 10 (public comment):

Item 1: Accepted (editorial)

Item 2: Accepted (editorial)


Comment 11 (public comment):

Item 1: Accepted (clarification)


Comment 12 (public comment):

Item 1: Explanation of why no change will be made


Comment 13 (public comment):

Item 1: Explanation of why no change will be made


Comment 14 (public comment):

Item 1: Accepted (clarification)


Comment 15 (public comment):

Item 1: Future XSL version


Comment 16 (public comment):

Item 1: Accepted (clarification)


Comment 17 (public comment):

Item 1: Explanation of XSL spec


Comment 18 (public comment):

Item 1: Explanation of XSL spec

Item 2: Accepted (bug in spec)


Comment 19 (public comment):

Item 1: Explanation of XSL spec


Comment 20 (public comment):

Item 1: Accepted (bug in spec)

Item 2: Explanation of XSL spec

Item 3: Explanation of why no change will be made

Item 4: Explanation of why no change will be made


Comment 21 (public comment):

Item 1: Accepted (editorial)


Comment 22 (public comment):

Item 1: Accepted (editorial)

Item 2: Accepted (editorial)


Comment 23 (public comment):

Item 1: Accepted (editorial)


Comment 24 (public comment):

Item 1: Explanation of why no change will be made


Comment 25 (public comment):

Item 1: Accepted (editorial)


Comment 26 (public comment):

Item 1: Accepted (editorial)


Comment 27 (public comment):

Item 1: Accepted (clarification)


Comment 28 (public comment):

Item 1: Explanation of why no change will be made


Comment 29 (public comment):

Item 1: Explanation of XSL spec


Comment 30 (public comment):

Item 1: Accepted (bug in spec)


Comment 31 (public comment):

Item 1: Accepted (clarification)


Comment 32 (public comment):

Item 1: Explanation of why no change will be made


Comment 33 (W3C staff editorial review):

Item 1: Accepted (editorial)

Item 2: Accepted (editorial)

Item 3: Explanation of why no change will be made

Item 4: Accepted (editorial)

Item 5: Accepted (editorial)

Item 6: Explanation of why no change will be made

Item 7: Accepted (editorial)

Item 8: Explanation of why no change will be made

Item 9: Explanation of why no change will be made

Item 10: Accepted (editorial)

Item 11: Accepted (editorial)

Item 12: Explanation of why no change will be made

Item 13: Accepted (editorial)

Item 14: Accepted (editorial)

Item 15: Accepted (editorial)

Item 16: Explanation of why no change will be made

Item 17: Accepted (editorial)

Item 18: Accepted (editorial)

Item 19: Accepted (editorial)

Item 20: Accepted (editorial)

Item 21: Accepted (editorial)

Item 22: Accepted (editorial)

Item 23: Accepted (editorial)

Item 24: Accepted (editorial)

Item 25: Accepted (editorial)

Item 26: Accepted (editorial)

Item 27: Accepted (editorial)

Item 28: Accepted (editorial)

Item 29: Accepted (editorial)

Item 30: Accepted (editorial)

Item 31: Accepted (editorial)

Item 32: Accepted (editorial)

Item 33: Accepted (editorial)

Item 34: Accepted (editorial)

Item 35: Accepted (editorial)

Item 36: Accepted (editorial)

Item 37: Accepted (editorial)

Item 38: Accepted (editorial)

Item 39: Accepted (editorial)

Item 40: Accepted (editorial)

Item 41: Accepted (editorial)

Item 42: Accepted (editorial)

Item 43: Accepted (editorial)

Item 44: Accepted (editorial)

Item 45: Accepted (editorial)

Item 46: Accepted (editorial)

Item 47: Accepted (editorial)

Item 48: Accepted (editorial)

Item 49: Accepted (editorial)

Item 50: Accepted (editorial)

Item 51: Accepted (editorial)

Item 52: Accepted (editorial)

Item 53: Accepted (editorial)

Item 54: Accepted (editorial)

Item 55: Accepted (editorial)

Item 56: Accepted (editorial)

Item 57: Accepted (editorial)

Item 58: Accepted (editorial)

Item 59: Accepted (editorial)

Item 60: Accepted (editorial)

Item 61: Accepted (editorial)

Item 62: Accepted (editorial)

Item 63: Accepted (editorial)

Item 64: Accepted (editorial)

Item 65: Accepted (editorial)

Item 66: Explanation of why no change will be made

Item 67: Accepted (editorial)

Item 68: Accepted (editorial)

Item 69: Accepted (editorial)

Item 70: Accepted (editorial)

Item 71: Accepted (editorial)

Item 72: Accepted (editorial)

Item 73: Accepted (editorial)

Item 74: Accepted (editorial)

Item 75: Accepted (editorial)


Comment 34 (XSL WG comment):

Item 1: Accepted (editorial)


Comment 35 (public comment):

Item 1: Accepted (editorial)

Item 2: Explanation of XSL spec

Item 3: Accepted (editorial)


Comment 36 (XSL WG comment):

Item 1: Accepted (editorial)

Item 2: Accepted (editorial)


Comment 37 (XSL WG comment):

Item 1: Accepted (editorial)


Comment 38 (XSL WG comment):

Item 1: Accepted (editorial)

Item 2: Accepted (clarification)

Item 3: Accepted (clarification)

Item 4: Accepted (bug in spec)

Item 5: Accepted (bug in spec)

Item 6: Accepted (editorial)

Item 7: Accepted (clarification)

Item 8: Accepted (editorial)

Item 9: Accepted (bug in spec)

Item 10: Accepted (clarification)

Item 11: Accepted (bug in spec)

Item 12: Accepted (editorial)

Item 13: Accepted (clarification)

Item 14: Accepted (editorial)

Item 15: Accepted (clarification)

Item 16: Accepted (clarification)


Comment 39 (public comment)

Accepted (bug in spec)