This document contains responses to comments sent to the Public XSL comment list
Message-Id: <200003290053.QAA18459@mail-345.corp.Adobe.COM> Date: Tue, 28 Mar 2000 16:56:51 -0800 To: xsl-editors@w3.org, w3c-svg-wg@w3.org From: Jon Ferraiolo <jferraio@Adobe.COM> Subject: Questions/comments on 7.11 Area Alignment Properties XSL Editors and SVG Working Group, The following comments are a set of initial questions and comments about section 7.11 of the XSL March 27 draft specification (http://www.w3.org/TR/2000/WD-xsl-20000327/slice7.html#section-N29442-Area-Alignment-Properties). This email stems from an initial review of this section of the XSL spec and comparison with the corresponding section of SVG's March 3 draft spec (http://www.w3.org/TR/2000/03/WD-SVG-20000303/text.html#BaselineAlignmentProperties). This email does NOT represent formal last call feedback from the SVG working group, although it is possible that some of the topics expressed in this email might be addressed in future formal correspondence. ISSUE/QUESTION WITH 'baseline-shift':
1) Based on discussions with Zilles in the past and looking at earlier
drafts of his paper on "Subdividing and Internationalizing Vertical Align"
and the description of the 'dominant-baseline' property when set to 'auto',
it appears that the intent of 'baseline-shift' is that not only would the
baseline tables get offset (a translation operation), but that the baseline
tables would be resized (a scaling operation) based on the current font size.
QUESTION: Is it true that 'baseline-shift' can cause both a shift and a
resizing of the baseline tables?
RECOMMENDED ACTION: If the answer is 'yes', then both the XSL spec and
the SVG spec need to be clear in the write-up of 'baseline-shift' that the
baseline tables might get resized.
Disposition: Accepted (clarification)
An introduction to this set of properties has been added and the text of "dominant-baseline" changed to be clearer.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
2) The XSL spec says that a 'baseline-shift' of '0cm' or '0%' is equivalent
to 'baseline'. That means that a 'baseline-shift' of '.001cm' might produce
wildly different results than a 'baseline-shift' of '.000cm', since one
might recompute the baseline table with a modified 'font-size' and the
other will not. This is a bad discontinuity. SVG is especially sensitive to
discontinuities because all properties are animatable.
RECOMMENDED ACTION: Change the definition of 'baseline-shift' in the
XSL and SVG specs to say that the baseline tables might be recomputed
whenever baseline-shift has a value other than 'baseline'.
Disposition: Accepted (clarification)
Text regarding scaling added to the description of "baseline-shift".
Links to the changed text in the XSL recommendation:
See link to changed text.
VARIOUS ISSUES WITH INITIAL VALUE FOR 'baseline-identifier':
3) The XSL spec clearly states what the semantics should be for
'baseline-identifier' when you have to resort to the initial value, but
there is no keyword for this behavior. With most (all?) other properties,
there is a keyword that corresponds to each set of behaviors.
RECOMMENDED ACTION: It seems to me that there should be a keyword
'auto' for 'baseline-identifier' whose behavior consists of the dominant
baseline of the script to which character belongs, or parent's dominant
baseline, if there is no such script, and that the initial value should be
'auto'.
Disposition: Accepted (bug in spec)
Links to the changed text in the XSL recommendation:
See link to changed text.
4) The SVG spec has confusing language about the initial value for
'baseline-identifier'. The introductory description to section 10.7.2
conveys the correct concept, but the property description is some
combination of confusing and incorrect.
RECOMMENDED ACTION: Fix the wording in the SVG spec to match the XSL spec.
Disposition: Out of scope; responsibility of other WG
Comment applies to the SVG spec and not the XSL spec.
SVG QUESTION ABOUT 'baseline-identifier'
5) 'baseline-identifier' has options 'before-edge', 'text-before-edge',
'after-edge' and 'text-after-edge'. The descriptions for these options
refer to various box model concepts which don't apply to SVG, which only
does single-line text.
QUESTION: For SVG, I believe that 'before-edge' and 'text-before-edge'
would be equivalent to 'hanging' (topmost baseline), whereas 'after-edge'
and 'text-after-edge' would be equivalent to 'ideographic' (bottommost
baseline). Is this correct?
RECOMMENDED ACTION: If the answer is 'yes', then change the SVG spec to
say that 'before-edge' and 'text-before-edge' is equivalent to 'hanging'
and that 'after-edge' and 'text-after-edge' is equivalent to 'ideographic'.
Disposition: Out of scope; responsibility of other WG
Comment applies to the SVG spec and not the XSL spec.
DISCREPANCIES BETWEEN XSL AND SVG THAT APPEAR TO REQUIRE CHANGES TO THE SVG SPEC:
6) 'baseline-identifier' in SVG has values 'top', 'text-top', 'bottom' and
'text-bottom' which are not part of the XSL spec.
RECOMMENDED ACTION: Remove these options from the SVG spec.
Disposition: Out of scope; responsibility of other WG
Comment applies to the SVG spec and not the XSL spec.
7) 'baseline-identifier' and 'dominant-baseline' in the SVG spec has option
'lower', but the XSL spec has option 'alphabetic'.
RECOMMENDED ACTION: Change the SVG spec to say 'alphabetic'
Disposition: Out of scope; responsibility of other WG
Comment applies to the SVG spec and not the XSL spec.
8) The XSL spec clearly indicates that the 'dominant-baseline' applies to
all text elements, and that the dominant baseline table gets resized with
each 'baseline-shift' when dominant-baseline='auto'.
RECOMMENDED ACTION: Change the SVG spec to say that 'dominant-baseline'
applies to ALL text elements, not just 'text'. Thus, you can change the
'dominant-baseline' on a 'tspan', for example. Also, the SVG spec needs to
be changed to say that the baseline table changes size with each
'baseline-shift' when dominant-baseline='auto'. With this change, then
'auto', 'autosense-script' and 'no-change' become differentiated and
meaningful with SVG.
Disposition: Out of scope; responsibility of other WG
Comment applies to the SVG spec and not the XSL spec.
Jon Ferraiolo SVG Editor
To: xsl-editors@w3.org > From: MURAKAMI Shinyu <murakami@nadita.com> Message-Id: <200003300608.EGI32515.BNVJBLSN@nadita.com> Date: Thu, 30 Mar 2000 06:08:09 +0900 Subject: minor bugs(?) Hello! Very minor bugs(?) I found in XSL Draft:
(1) TOC level problem
In [Table of contents]:
7.20 Properties for Links
7.20.1 active-state
7.21 auto-restore
...
7.30 switch-to
7.31 Properties for Markers
...
I think it shuld be:
7.20 Properties for Links
7.20.1 active-state
7.20.2 auto-restore
...
7.20.11 switch-to
7.21 Properties for Markers
...
Disposition: Accepted (editorial)
The properties from "active-state" to "switch-to" are all under the heading "Properties for Links".
(2) area-class trait: "normal" or "xsl-normal" ? In [4.2.5 Stacking Constraints]: >The area-class trait is an enumerated value which is xsl-normal for ... but in [6.1.1 Definitions Common to Many Formatting Objects]: >The values for this trait are: "normal", ...
Disposition: Accepted (editorial)
"xsl-normal" is the correct value.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
(3) "div" or "/" ? In [5.9.1 Number Functions]: >...such as: "floor(1.4in/1.0in)*1.0in" must be used. I think such as: "floor(1.4in div 1.0in)*1.0in" must be used.
Disposition: Accepted (editorial)
"div" replaces "/".
Links to the changed text in the XSL recommendation:
See link to changed text.
-- MURAKAMI Shinyu
To: xsl-editors@w3.org From: MURAKAMI Shinyu <murakami@nadita.com> Message-Id: <200004032014.DGE80716.NBNJBSLV@nadita.com> Date: Mon, 3 Apr 2000 20:14:00 +0900 Subject: Accessibility feature of XSL-FO XSL-FO WD spec defines a set of Common Accessibility Properties: "source-document" and "role". I think the "role" property is very important for people with special needs, especially for the blind.
But I can not understand how to put the ALT-text for the fo:external-graphic or fo:instream-foreign-object using the "role" property. Or it's not a role of the "role" property? In the description of the "role" property: > It can, for example, be an element name in some known semantic > vocabulary, such as HTML, or a particular Web Accessibility > Initiative (WAI) semantic vocabulary.
Disposition: Explanation of XSL spec
The intended usage in this case is to create an fo:inline role="ALT-text" containing the textual content of the ALT-text attribute. Note that this is only ONE of the many ways the xsl stylesheet designer could decide to handle this attribute.
An element name in HTML can not describe the ALT-text. And the "WAI semantic vocabulary", I don't know about it. Where can I find the "WAI semantic vocabulary"? Why not standardize the "role" vocabulary? -- it's not useful the "some known semantic vocabulary". "some known" is equivalent to "unknown" for many user agents and users. I think, for graphic objects, HTML-like "alt" property is convenient. Simple example: <fo:external-graphic src="photo001.jpg" alt="(My photo)"/>
Disposition: Accepted (new functionality)
Please see the response to Comment 23 item 4.
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.
I love XSL. And I expect the answer to the famous statement "Formatting Objects considered harmful" -- http://www.operasoftware.com/people/howcome/1999/foch.html
Disposition: Accepted (clarification)
The XSL WG appreciates your sentiment towards XSL. We expect that the following paragraph, which is being inserted at the end of section 1.1.1 Tree Transformation of the Introduction of the XSL document, will provide the answer you request:
In some implementations of XSL/XSLT, the result of tree construction can be output as an XML document. This would allow an XML document which contains formatting objects and formatting properties to be output. This capability is neither necessary for an XSL processor nor is it encouraged. There are, however, cases where this is important, such as a server preparing input for a known client; for example, the way that a WAP [http://www.wapforum.org/faqs/index.htm] server prepares specialized input for a WAP capable hand held device. To preserve accessibility, designers of Web systems should not develop architectures that require (or use) the transmission of documents containing formatting objects and properties unless either the transmitter knows that the client can accept formatting objects and properties or the transmitted document contains a reference to the source document(s) used in the construction of the document with the formatting objects and properties.
Links to the changed text in the XSL recommendation:
See link to changed text.
Thank you, MURAKAMI Shinyu
Message-ID: <39B19660C174D311BB9000A0C9E01C3F18BA86@corfu.rnib.org.uk> From: "Pawson, David" <DPawson@rnib.org.uk> To: "'xsl-editors@w3.org'" <xsl-editors@w3.org> Date: Tue, 4 Apr 2000 09:54:34 +0100 Subject: Deprecated
<quote>5.7.1 Text-transform Property The case changes specified by this property are carried out during refinement by changing the value of the "character" property appropriately. NOTE: The use of the "text-transform" property is deprecated in XSL due to its severe internationalization issues. </quote> Why are deprecated items being written into a new W3C draft? If they are deprecated (for a valid reason here), then why include them?
Disposition: Explanation of why no change will be made
XSL has had as a goal to maintain CSS compatibility as far as is practible. This property has been included to enable easier support for automated conversion from CSS stylesheets into XSL stylesheets. That doesn't mean that all such properties make sense for use in a transformation-driven style language, so some properties are deprecated, but they must be provided for use in simple mappings from CSS.
Regards, DaveP Advisory Committe representative, RNIB.
Message-ID: <39B19660C174D311BB9000A0C9E01C3F18BA87@corfu.rnib.org.uk> From: "Pawson, David" <DPawson@rnib.org.uk> To: "'xsl-editors@w3.org'" <xsl-editors@w3.org> Date: Tue, 4 Apr 2000 10:19:03 +0100
Subject: ex as a unit I note that the ex has gone as a unit since the January WD, its no longer listed in the 27 Mar WD If the em is to be included, then surely the ex should also be available. My use case is for scaling print sizes up for users of large print. Regards, DaveP
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0024.html
Message-Id: <3.0.5.32.20000415110220.0121aec0@mail-321>
Date: Sat, 15 Apr 2000 11:02:20 -0700
To: "Pawson, David" <DPawson@rnib.org.uk>, "'xsl-editors@w3.org'" <xsl-editors@w3.org>
From: Stephen Deach <sdeach@Adobe.COM>
Subject: Re: ex as a unit
[I have a bad keyboard -- typos corrected in this copy. I also made some
modifications to the wording of items 4 & 5. ---SDeach]
At this time, this is a personal opinion, and does not reflect a decision
of the XSL-WG. This is provided as input for that evaluation.
There are multiple problems with "ex" as a unit:
1.) It is only meaningful for latin-based (and similar) typefaces. It is
not useful for Arabic, Indic, Ideographic or a number of other scripts. In
fact there is no way to determine the ex" height (or analogous measurement)
of many of these faces (since there is no analogous concept).
2.) Most typefaces in widespread distribution have no "ex" height in the
font metric information, it must be derived by inspecting the character
shapes of selected letters (usually the lower-case x).
3.) Type size is specified using the typebody height for all widespread
typefaces and composition systems, thus EM is a useful and well-defined
unit. If one wished to scale up the layout based on type-size, the EM is a
much better choice since it avoids disproportionate changes in line-spacing
(resulting in either disproportionately wide line-spacing or
overlapping-lines) and layout that occur if EX-Height is used. To fix this
disproportionate spacing, one must consult the EM-height anyway, so it is
better to use EM units in the first place.
4.) Though ex-height has some value in determining the range of size
adjustment [especially the minimum size] for legibility of latin-related
typfaces, the font-size-adjust property seems an adequate mechanism for
doing this. Retaining "ex" as a general unit does not seem necessary.
5.) This decision was made in a joint meeting of the XSL-WG with CSS & WAI
representatives in Sophia-Antipolis, May 5, 1999; but the change was not
reflected in the April 1999 draft. [Two votes were recorded in the
Wednesday minutes under discussion of Item 2:
Proposal: That the XSL WG not implement exes; no objection.
Proposal: That the XSL WG recommend that the CSS WG withdraw or
deprecate the use of exes; no objection.
]
At 10:19 2000-04-04 +0100, Pawson, David wrote:
>I note that the ex has gone as a unit since
>the January WD, its no longer listed in
>the 27 Mar WD
>
>If the em is to be included, then surely the ex
>should also be available. My use case is for
>scaling print sizes up for users of large print.
>
>Regards, DaveP
>
>
>
-----------------------------------------------------------------------------
This e-mail reflects the personal opinion of the author.
-- Unless explicitly so stated in the text, it does not represent an
official position of Adobe Systems, Inc.
-- Unless explicitly so stated in the text, it does not represent an
official opinion of the W3C XSL Working group.
-----------------------------------------------------------------------------
Stephen Deach | Sr Computer Scientist
408-536-6521 (office) | Adobe Systems Inc.
408-537-4214 (fax) | Mail Stop W15-424
sdeach@adobe.com (no ads) | 345 Park Ave
| San Jose, CA 95110-2704
| USA
----------------------------------------------------------------------------
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0025.html
Message-Id: <3.0.5.32.20000417072501.0177d7f0@mail-321>
Date: Mon, 17 Apr 2000 07:25:01 -0700
To: xsl-editors@w3.org
From: Stephen Deach <
sdeach@Adobe.COM>
Subject: RE: ex as a unit
>From: "Pawson, David" <DPawson@rnib.org.uk>
>To: "'Stephen Deach'" <sdeach>
>Subject: RE: ex as a unit
>Date: Mon, 17 Apr 2000 08:52:23 +0100
>X-Mailer: Internet Mail Service (5.5.2650.21)
>
>Thanks for the detailed response. Logic accepted.
>
>Simple use-case need then.
>
>to present customer driven clear/large print, I only specify
>one base-font size in the XSLT stylesheet. All other sizes
>are derived from this by factoring up or down.
>This permits automated provision of documents to user
>specification ( I want 18 point please) dependant on
>their visual acuity at the time.
>
>I *had* been using a multiplier with ex unit to do this.
>
>Suggestions for a solution to my dilema?
>
>Regards, DaveP
>
>
-----------------------------------------------------------------------------
This e-mail reflects the personal opinion of the author.
-- Unless explicitly so stated in the text, it does not represent an
official position of Adobe Systems, Inc.
-- Unless explicitly so stated in the text, it does not represent an
official opinion of the W3C XSL Working group.
-----------------------------------------------------------------------------
Stephen Deach | Sr Computer Scientist
408-536-6521 (office) | Adobe Systems Inc.
408-537-4214 (fax) | Mail Stop W15-424
sdeach@adobe.com (no ads) | 345 Park Ave
| San Jose, CA 95110-2704
| USA
----------------------------------------------------------------------------
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0026.html
Message-Id: <3.0.5.32.20000417072830.0177e1e0@mail-321>
Date: Mon, 17 Apr 2000 07:28:30 -0700
To: "Pawson, David" <DPawson@rnib.org.uk>
From: Stephen Deach <sdeach@Adobe.COM>
Cc: xsl-editors@w3.org
Subject: RE: ex as a unit
Why wouldn't EM units work for this?
At 08:52 2000-04-17 +0100, Pawson, David wrote:
>Thanks for the detailed response. Logic accepted.
>
>Simple use-case need then.
>
>to present customer driven clear/large print, I only specify
>one base-font size in the XSLT stylesheet. All other sizes
>are derived from this by factoring up or down.
>This permits automated provision of documents to user
>specification ( I want 18 point please) dependant on
>their visual acuity at the time.
>
>I *had* been using a multiplier with ex unit to do this.
>
>Suggestions for a solution to my dilema?
>
>Regards, DaveP
>
>
-----------------------------------------------------------------------------
This e-mail reflects the personal opinion of the author.
-- Unless explicitly so stated in the text, it does not represent an
official position of Adobe Systems, Inc.
-- Unless explicitly so stated in the text, it does not represent an
official opinion of the W3C XSL Working group.
-----------------------------------------------------------------------------
Stephen Deach | Sr Computer Scientist
408-536-6521 (office) | Adobe Systems Inc.
408-537-4214 (fax) | Mail Stop W15-424
sdeach@adobe.com (no ads) | 345 Park Ave
| San Jose, CA 95110-2704
| USA
----------------------------------------------------------------------------
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0027.html
Message-Id: <3.0.5.32.20000419064510.0083ea00@mail-321>
Date: Wed, 19 Apr 2000 06:45:10 -0700
To: xsl-editors@w3.org
From: Stephen Deach <sdeach@Adobe.COM>
Subject: RE: ex as a unit
>From: "Pawson, David" <DPawson@rnib.org.uk>
>To: "'Stephen Deach'" <sdeach>
>Subject: RE: ex as a unit
>Date: Wed, 19 Apr 2000 07:40:20 +0100
>X-Mailer: Internet Mail Service (5.5.2650.21)
>
>My lack of knowledge of the print industry is showing :-)
>It probably would, just that our printers have always
>talked of vertical spacing as being in ex units.
>
>I need to set space-before, after, font sizes etc
>all relative to the base unit, so I guess em is
>as relative as I'm going to get!
>
>Thanks for your time Stephen.
>
>Regards, DaveP
>
>
>
>>Why wouldn't EM units work for this?
>>
>>At 08:52 2000-04-17 +0100, Pawson, David wrote:
>>>Thanks for the detailed response. Logic accepted.
>>>
>>>Simple use-case need then.
>>>
>>>to present customer driven clear/large print, I only specify
>>>one base-font size in the XSLT stylesheet. All other sizes
>>>are derived from this by factoring up or down.
>>>This permits automated provision of documents to user
>>>specification ( I want 18 point please) dependant on
>>>their visual acuity at the time.
>>>
>>>I *had* been using a multiplier with ex unit to do this.
>>>
>>>Suggestions for a solution to my dilema?
>
>
-----------------------------------------------------------------------------
This e-mail reflects the personal opinion of the author.
-- Unless explicitly so stated in the text, it does not represent an
official position of Adobe Systems, Inc.
-- Unless explicitly so stated in the text, it does not represent an
official opinion of the W3C XSL Working group.
-----------------------------------------------------------------------------
Stephen Deach | Sr Computer Scientist
408-536-6521 (office) | Adobe Systems Inc.
408-537-4214 (fax) | Mail Stop W15-424
sdeach@adobe.com (no ads) | 345 Park Ave
| San Jose, CA 95110-2704
| USA
----------------------------------------------------------------------------
Disposition: Explanation of why no change will be made
The arguments made in the discussion comments above for the reasons for not including the "ex" unit have been accepted by the submitter of the comment.
Date: Wed, 5 Apr 2000 17:53:37 +0100 Message-ID: <4095-Wed05Apr2000175337+0100-sebastian.rahtz@oucs.ox.ac.uk> From: "Sebastian Rahtz" <sebastian.rahtz@computing-services.oxford.ac.uk> To: xsl-editors@w3.org cc: xsl-list@mulberrytech.com Subject: generating eg PDF bookmarks from XSL FO
About 9 months, I asked whether XSL FO would put in some objects in
which I could store material to be presented in (eg) PDF bookmarks.
At that time, I used an extension like this:
<fo:block
<fotex:bookmark
xmlns:fotex="http://www.tug.org/fotex"
fotex-bookmark-level="2"
fotex-bookmark-label="foo">Introduction</fotex:bookmark>
Introduction: the way it is
</fo:block>
which set a normal block with the words "Introduction: the way it is",
and establish a second-levek `heading' with the words
"Introduction". This translates straightforwardly into PDF bookmarks,
and no doubt other systems can do something similar.
Looking at the 27th March XSL draft, I still cannot see any official
way to produce the desired effect. Can anyone comment? If there is no
plan to include it, I will keep on with my extension, but I would
prefer not to...
Disposition: Explanation of why no change will be made
The XSL group feels that this specific functionality is out of scope for standardizing in XSL FOs; implementing this functionality as a proprietary extension is more appropriate.
Sebastian Rahtz
Date: Wed, 5 Apr 2000 18:02:38 +0100 Message-ID: <3167-Wed05Apr2000180238+0100-sebastian.rahtz@oucs.ox.ac.uk> From: "Sebastian Rahtz" <sebastian.rahtz@computing-services.oxford.ac.uk> To: xsl-editors@w3.org cc: xsl-list@mulberrytech.com Subject: XSL FO conformance
In the March 27th draft, section 8 discusses conformance; for formatting objects, Appendix B says whether or not an FO is "basic" or "extended". But Appendix C does not do the same for properties. Is there a list somewhere which I have missed?
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0013.html
Message-Id: <3.0.32.20000405144231.0177bb00@pophost.arbortext.com> Date: Wed, 05 Apr 2000 14:42:43 -0500 To: xsl-editors@w3.org From: Paul Grosso <pgrosso@arbortext.com> Subject: Re: XSL FO conformance At 18:02 2000 04 05 +0100, Sebastian Rahtz wrote: >In the March 27th draft, section 8 discusses conformance; for >formatting objects, Appendix B says whether or not an FO is "basic" or >"extended". But Appendix C does not do the same for properties. Is >there a list somewhere which I have missed? See "C.3 Property Table: Part II", the fifth column of that table. ... paul
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0014.html
From: "Sebastian Rahtz" <sebastian.rahtz@computing-services.oxford.ac.uk> Message-ID: <14571.40801.651777.236482@localhost.localdomain> Date: Wed, 5 Apr 2000 21:17:37 +0100 (BST) To: xsl-list@mulberrytech.com Cc: xsl-editors@w3.org Subject: Re: XSL FO conformance Paul Grosso writes: > >"extended". But Appendix C does not do the same for properties. Is > >there a list somewhere which I have missed? > > See "C.3 Property Table: Part II", the fifth column of that table. fifth column? I only see 3. I assume Netscape has failed to print the subsequent ones.... grrr. <irony>any chance of a version of the XSL FO spec produced using a decent XSL FO engine?</irony> ... sebastian
Disposition: Explanation of XSL spec
As the submitter says: scroll horizontally...
Also on conformance:
a) why is <table-footer> extended, but <table-header> basic? why would anyone be able to implement one but not the other?
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0013.html
Message-Id: <3.0.32.20000405144231.0177bb00@pophost.arbortext.com> Date: Wed, 05 Apr 2000 14:42:43 -0500 To: xsl-editors@w3.org From: Paul Grosso <pgrosso@arbortext.com> Subject: Re: XSL FO conformance At 18:02 2000 04 05 +0100, Sebastian Rahtz wrote: ... >Also on conformance: > >a) why is <table-footer> extended, but ><table-header> basic? why would anyone be able to implement one but >not the other? The OASIS (nee SGML Open) Exchange Table Model [1] that is one of the most widely implemented ones includes table headers but not table footers. So in this case, it might not be "able to implement" issues, but "already deployed software, interfaces, documents, and user-education" issues that put table-footer in the extended category. Certainly, that is my position. ... paul [1] http://www.oasis-open.org/html/a503.htm
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0014.html
From: "Sebastian Rahtz" <sebastian.rahtz@computing-services.oxford.ac.uk> Message-ID: <14571.40801.651777.236482@localhost.localdomain> Date: Wed, 5 Apr 2000 21:17:37 +0100 (BST) To: xsl-list@mulberrytech.com Cc: xsl-editors@w3.org Subject: Re: XSL FO conformance Paul Grosso writes: ... > The OASIS (nee SGML Open) Exchange Table Model [1] that is one of the > most widely implemented ones includes table headers but not table > footers. So in this case, it might not be "able to implement" > issues, but "already deployed software, interfaces, documents, > and user-education" issues that put table-footer in the extended > category. Certainly, that is my position. thanks. I will not say I agree with the philosophy (!), but now I understand. ... sebastian
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0028.html
From: "Sebastian Rahtz" <sebastian.rahtz@computing-services.oxford.ac.uk>
Message-ID: <14595.6221.631695.776796@localhost.localdomain>
Date: Sun, 23 Apr 2000 16:35:41 +0100 (BST)
To: xsl-list@mulberrytech.com
cc: xsl-editors@w3.org
Subject: Re: XSL FO conformance
Eduardo Gutentag writes:
> I am a bit puzzled by your words. You started this thread by asking
> (http://www.mulberrytech.com/xsl/xsl-list/archive/msg10922.html)
>
> ---
> why is <table-footer> extended, but
> <table-header> basic? why would anyone be able to implement one but
> not the other?
....
> But if you read the conformance section of the working draft
> (http://www.w3.org/TR/xsl/slice8.html#section-N54274-Conformance)
> you will see that "basic" is intended for applications that need to
> support a minimum level of pagination while "extended" is intended
> for applications "whose goal is to provide sophisticated pagination."
> It's just a matter of what is or might be your application's goal
> and or capabilities.
Sure, I understand that. I think that what worried me was the apparent
division into "basic" and "extended" being based on the capabilities
of existing software. I would have expected more objectivity.
> I am not sure why you would consider that the various levels of conformance
> cripple the system, or target a specific set of software.
because the distinction between basic and extended seems blurred. on
the one hand, it is a matter of whether or not one needs decent
pagination; but on the other hand, it seems that table footers and
headers are split apart on the basis of what current software does
> The differenciation
> between table-header and table-footer that you point out is based on
> the acknowledgment that existing implementations (albeit not of XSL ;-) *do*
> make a differenciation between one and the other, and therefore future
> implementations might also want to make this distinction.
I can see the argument, but I find it hard to agree with. What does a
theoretical system like XSL have to with current practice? If you
*are* being influenced by existing capabilities, I'd like to see
considerably more information on the details and the arguments.
> While it is not beyond the realm of the possible that the XSL WG has made
> mistakes, I think this is not one of them.
Possibly I mistook the way XSL FO is going. I saw it as a rewrite of
DSSSL, with varioius constraints:
a) expressing everthing in XML
b) making sure that all the work done on CSS was explicitly
referenced and mappped to the relevent part of the new language
I assumed that, like DSSSL, XSL FO was designed with no constraints
about what was currently possible or implemented.
I'm summary, I would argue that the current spec seems to confuse
a theoretical "simple vs sophisticated pagination" distinction with a
"needed for conformance with current standards vs
theoretically achievable distinction.
Sebastian
Disposition: Explanation of why no change will be made
It is the intent of the XSL WG that implementations will implement both Basic and Extended levels. Basic conformance was designed to give implementors a coherent starting point and at the same time allowing for future enhancement.
b) I fear I miss an explanation of how to do lists in "basic" mode, without <list-item-label>. can anyone expound?
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0013.html
Message-Id: <3.0.32.20000405144231.0177bb00@pophost.arbortext.com> Date: Wed, 05 Apr 2000 14:42:43 -0500 To: xsl-editors@w3.org From: Paul Grosso <pgrosso@arbortext.com> Subject: Re: XSL FO conformance At 18:02 2000 04 05 +0100, Sebastian Rahtz wrote: ... >b) I fear I miss an explanation of how to do lists in "basic" mode, >without <list-item-label>. can anyone expound? Table B5 says (for list-item-label) "extended; fallback: labels that break across multiple lines are treated as separate blocks before list-item-body." I believe that is intended to mean that *some* implementation of list-item-label (i.e., that described as the fallback) must be implemented in all (e.g., basic) implementations, but the full semantic (that also handles multi-line labels) is an extended feature. paul
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0014.html
From: "Sebastian Rahtz" <sebastian.rahtz@computing-services.oxford.ac.uk> Message-ID: <14571.40801.651777.236482@localhost.localdomain> Date: Wed, 5 Apr 2000 21:17:37 +0100 (BST) To: xsl-list@mulberrytech.com Cc: xsl-editors@w3.org Subject: Re: XSL FO conformance Paul Grosso writes: ... > list-item-body." I believe that is intended to mean that *some* > implementation of list-item-label (i.e., that described as the fallback) > must be implemented in all (e.g., basic) implementations, but the full > semantic (that also handles multi-line labels) is an extended feature. ok, thats fine. i am now clearer on this bit sebastian
Disposition: Accepted (clarification)
Text in introduction of B changed to make it clear what "extended" means.
Links to the changed text in the XSL recommendation:
See link to changed text.
Sebastian "hoping for basic conformance" Rahtz
Message-Id: <3.0.5.32.20000407075052.0083eec0@mail-321> Date: Fri, 07 Apr 2000 07:50:52 -0700 To: Norman Walsh <nwalsh@arbortext.com> From: Stephen Deach <sdeach@Adobe.COM> Cc: xsl-editors@w3.org Subject: Re: table-layout="fixed" and table width Norm,
Your interpretation would have been the interpretation I would have intended. Lets see what Anders & Paul think. (I interpret fixed [when no overall width for the whole table is specified] as: 1.) take the specified widths of any individual columns 2.) take the "natural width" of the widest item in each of the remaining columns. This sum of all 1's and 2's is the overall width of the table. Fixed means "do not reflow text in cells to make it fit into the width of the parent container". I need to re-read the spec to see if it is worded to exclude it. I am copying this email to xsl-editors, so it gets journaled with other last-call questions/issues. At 08:58 2000-04-07 -0400, you wrote: >David Carlisle and I are interpreting the XSL spec >differently. It boils down to this question: can I specify >table-layout="fixed" but leave the width of the table >unspecified? (Effectively requiring the implementation to use >the natural width of the table as the total amount of space for >distributing column widths.) > >I think the answer is yes. Please tell me I'm right. :-) > > Be seeing you, > norm > >-- >Norman Walsh <nwalsh@arbortext.com> | Not everyone can live upstream. >Principal Software Engineer | >Arbortext, Inc. (www.arbortext.com) | >413.256.6985 Voice/FAX | > > >
Disposition: Explanation of XSL spec
As per CSS interpretation (by Bert Bos) table-layout="fixed" and with="auto" is a legal specification and (as XSL spec states in 6.7.3) says that then the automatic table layout shall be used.
-----------------------------------------------------------------------------
This e-mail reflects the personal opinion of the author.
-- Unless explicitly so stated in the text, it does not represent an
official position of Adobe Systems, Inc.
-- Unless explicitly so stated in the text, it does not represent an
official opinion of the W3C XSL Working group.
-----------------------------------------------------------------------------
Stephen Deach | Sr Computer Scientist
408-536-6521 (office) | Adobe Systems Inc.
408-537-4214 (fax) | Mail Stop W15-424
sdeach@adobe.com (no advertizing) | 345 Park Ave
| San Jose, CA 95110-2704
| USA
----------------------------------------------------------------------------
To: xsl-editors@w3.org From: MURAKAMI Shinyu <murakami@nadita.com> Message-Id: <200004080321.IIE52035.NBVLSJBN@nadita.com> Date: Sat, 8 Apr 2000 03:21:59 +0900 Subject: Initial Value of "format" property Hi,
The XSL WD(2000-03-27) [7.32.1 "format"] [C Property Index] says the Initial value of "format" property is "1." (including a period!) I think this must be simple "1" (very normal page-number format), am I wrong?
Disposition: Explanation of why no change will be made
This property is copied from XSLT and we believe that it is important that both definitions, including the initial value, is the same.
MURAKAMI Shinyu
Message-ID: <008401bfa452$2544c280$0278e8c3@fvbasten> From: "Frans van Basten" <fvbasten@bakkenist.nl> To: <xsl-editors@w3.org> Date: Wed, 12 Apr 2000 09:38:47 +0200 Subject: Fw: XSL specification ----- Original Message ----- From: "Frans van Basten" <fvbasten@bakkenist.nl> To: <sca@us.ibm.com> Cc: <alrb@us.ibm.com>; "Paul Vriend" <pvriend@bakkenist.nl> Sent: woensdag 12 april 2000 9:37 Subject: XSL specification > Dear Sharon,
> I've read the specification of XSL in order to be able to create XSL > stylesheets to view XML files in the browser. > I expected to find somewhere the syntax description of XSL, for instance how > to use the <xsl:for-each> and <xsl:select> statements. However, there is > not a single reference to these kind of XSL statements.
Disposition: Explanation of XSL spec
This information is contained in the XSLT Specification. XSL is the library of Formatting Objects and their properties. XSLT is used to create the result tree that contains formatting objects and properties.
> What I specifically want to know is, if it is possible to nest > <xsl:for-each> statements for viewing information of an XML document > correctly nested in the browser. I tried to do it, but it didn't work. > > Could you please tell me where I can find information and examples about XSL > statements for viewing XML documents in the browser.
Disposition: Explanation of XSL spec
For XSLT this information is contained in a variety of books and tutorials and browser vendor documentation that are publically available. See the XSL public mailing list at the following: www.mulberrytech.com.
> Regards, > > Frans van Basten > > Deloitte & Touche Bakkenist > Wisselwerking 46 > 1112 XR Diemen > P.O. Box 23103 > 1100 DP Amsterdam > the Netherlands > Tel: +31 20 495 2323 > Fax: +31 20 495 2345 > Mobile: +31 6 2251 0303 > e-mail: fvbasten@bakkenist.nl > www: www.bakkenist.nl > ----------------------------------------------------
Message-Id: <v04210100b529c55d7f5b@[24.25.222.186]> Date: Mon, 24 Apr 2000 01:39:01 -0800 To: xsl-editors@w3.org From: Susan Lesch <lesch@w3.org> Cc: w3t-comm@w3.org Subject: minor comments for WD-xsl-20000327 Here are minor editorial comments for your XSL Last Call Working Draft [1] "work in progress." I have so far only read it once, and found remarkably few typos for such a long spec. Please feel free to use or ignore these, as you see fit. There are no suggestions for substantive changes here. Comments --------
It would be nice if when pointing to other parts of the spec. (e.g., "see the section on areas", or "please consult...") there was always a link.
Disposition: Accepted (editorial)
A number of links have been added.
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.
Traits, properties, and values are sometimes marked up, sometimes in
apostrophes ('), and sometimes in double quotes ("). It would be nice
if there was a consistent markup style for them all, throughout the
specification.
Disposition: Explanation of why no change will be made
We agree that it would be nice if the quotation was consistent, but in addition to changes in the XSL text it would require changes to quoted text as well.
I wasn't sure if you intend to use the key words "SHALL" and "MUST" in accord with RFC 2119. If you do, there should be a mention of this in the Introduction with a link in References to http://www.ietf.org/rfc/rfc2119.txt
Disposition: Explanation of XSL spec
We did not use RDF 2119. We use "shall" for an absolute requirement in the XSL text. The text quoted from CSS typically uses "must".
slice1 is a great introduction. You might include one even simpler diagram showing a formatting object, trait, property and value, with the parts labeled.
Disposition: Accepted (clarification)
A graphic showing a summary has been added.
Links to the changed text in the XSL recommendation:
See link to changed text.
The illustrations need "alt" text.
Disposition: Explanation of why no change will be made
The graphics tend to be very complex and thus a simple alt-text would be of little value and the figure captions should be used instead.
Globally, since it's not a proper noun, "User Agent" could read "user agent." Also, "recommendation" could be "Recommendation".
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.
slice6 has a few candidates for ordered lists. In context, (1), (2), ... and (a), (b), ... are clear, but I wondered if you wanted OLs.
Disposition: Explanation of why no change will be made
In most cases the XSL group prefers the "inlined" style for these kinds of lists.
In slice6, the trait value true starts out <code>true</code> and then in 6.5.3 and later becomes quoted "true" with no markup. Because this is a long and complex page, I'm in favor of markup for all occurrences, and possibly for all trait values.
Disposition: Explanation of why no change will be made
It is not clear how much of an improvement this would be and the available effort is better spent elsewhere.
In slice7, "white space", "whitespace" and "white-space" appear. Which is correct? I'd make all occurrences match.
Disposition: Explanation of why no change will be made
These have been reviewed and can't be changed in the XSL specfication. All 3 variations are used with the following specific meanings in existing W3C Recommendations:
The term "white space" is used in the XML Recommendation as a character class.
The term "white-space" is the property name in the CSS Recommendation.
The term "whitespace" is used in the CSS Recommendation as the generic for anything that is of class "white space".
We can't change the usage in the CSS excerpts and we use each of these terms in all other cases in the manner consistent with these definitions.
In slice7, "Definition" and "Reference" don't need to be capitalized; each occurrence could read "CSS definition:", "CSS reference:" and "XSL definition:".
Disposition: Explanation of why no change will be made
The XSL working group think the current style is better.
Also in slice7, each "Property Derived from a CSS2 Property." can perhaps read, "Property derived from a CSS2 property". "Writing-mode Relative Equivalent of CSS2 Property." could be, "Writing-mode relative equivalent of a CSS2 property". Or, since they don't appear to be headings or members of a class, these could be sentences.
Disposition: Accepted (editorial)
An "a" will be added, but the capitalization will be retained.
A minor point: I didn't understand why the initial value for "format" (both in 7.32.1 and in Appendix C) is "1." rather than "1" or "1.0".
Disposition: Explanation of why no change will be made
See Comment 9 item 1.
Minor typos ----------- From here on, a section number is followed by a quote, and then some idea for an improvement. Comments are in brackets [].
1.1.2 par. 7 mark-up markup [It's a dictionary word.]
Disposition: Explanation of why no change will be made
The text has been removed so this comment is no longer applicable.
1.2.1 par. 2, 1.2.3 par. 1 and 2 side-bars sidebars [It's a dictionary word.]
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.
1.2.1 last item XSL only XSL-only
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
1.2.5 par. 2 more, see more. See [or "more; see"]
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
two directions, two directions:
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
2.2 last par. lower-case lowercase [It's a dictionary word.]
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
3. par. 3 (see [7 Formatting Properties] (see [7 Formatting Properties])
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
3. par. 6 last list item attribute, attribute
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
3.1 par. 4 areas, instead areas; instead
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
4.1 par. 5 copied from property of the same copied from a property of the same
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
4.2.2 par. 6 dimensions dimensions.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
4.3.1 list item 3 par. 2 there are at two there are two
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
4.14 [I didn't understand the purpose of the list of traits on areas.]
Disposition: Explanation of why no change will be made
We believe this list is a useful summary of material scattered throughout the "Area Model" section.
5.2 par. 2 Note conformance level; "complete". conformance level: "complete".
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
5.2 - last list, list item 2 initial-value initial value
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
5.3 par. 2 correspondance correspondence
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
5.3 - last "if" even-numbered lined: even-numbered lines:
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
5.3 last par., and 5.3.1 par. 1 correspondance correspondence
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
5.8.3 |Numeric | Numeric
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
5.8.9 RGB and ICC [spell out the first time they are used: RGB (Red, Blue, Green) and ICC (International Color Consortium)]
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
5.8.13.1 [... CSS2/syndata.html#x39] [CSS2 section 4.3.2]
Disposition: Accepted (editorial)
Changed to a link with the usual presentation.
Links to the changed text in the XSL recommendation:
See link to changed text.
0.28mm [approximately 1/90] [Was the reference pixel not changed to 1/96"?]
Disposition: Explanation of why no change will be made
The definition used is based on CSS2 (plus the published errata to CSS2) where no change of the 1/90 value has been made. Thus the text needs to refer to 1/90 rather than 1/96.
5.9.2 icc-color the an ICC Color Profile an ICC Color Profile
Disposition: Accepted (editorial)
Changed to "the".
Links to the changed text in the XSL recommendation:
See link to changed text.
5.9.4 from-parent and from-nearest-specified-value expands; each expands, each
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
5.10 par. 2 a the "space-before" property the "space-before" property
Disposition: Accepted (editorial)
Changed to "a".
Links to the changed text in the XSL recommendation:
See link to changed text.
5.10 par. 8 forms; the complete forms having forms; the complete forms have [or:] forms, the complete forms having
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.1 par. 1 See [3 Introduction toFormatting].The See [3 Introduction to Formatting]. The
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.3 external-graphic xml result tree XML result tree
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.3 simple-page-master up to five regions up to five regions.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.3 table-cell in a table-cell. in a table cell.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
6.4.1.2 - 2nd to last par. It is expected, that It is expected that
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.4.1.3 par. 2 We will say an An
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.4.1.5 region to which the flow is assigned, except that [This sentence is really long; here's one way to clarify:] region to which the flow is assigned with two exceptions:
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.4.7 Constraints need not be onto; need not be one to one; [?]
Disposition: Explanation of why no change will be made
The proposed change would make the sentence technically incorrect.
6.4.9 Constraints the sub-sequence of pages consist of the sub-sequence of pages consists of
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.4.11 Constraints par. 2 Since, the Since the
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.4.11 Constraints par. 3 and 4 trait is true, if trait is true if
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
6.4.11 par. 5 ["(1) if", "(2) if", "(3) if" might make more sense as "if (1)..., and (2)..., and (3)...".]
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.
6.4.12 - 1st illustration [Could the white area around region-body be labeled?]
Disposition: Accepted (clarification)
Some explanatory text will be added as a figure caption.
Links to the changed text in the XSL recommendation:
See link to changed text.
6.4.12 Areas - par. 2 appear; that is, appear, that is,
Disposition: Explanation of why no change will be made
6.4.12 Constraints - 1st par. after 1st Note measured from "top" to "bottom" For measured from "top" to "bottom". For
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.4.13, 6.4.14, 6.4.15, 6.4.16, and 6.4.17 Common Usage ; that is, whether , that is, whether
Disposition: Explanation of why no change will be made
6.4.13, 6.4.14, 6.4.15, 6.4.16, and 6.4.17 Common Usage clipped by the its parent clipped by its parent
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.
6.4.13 Common Usage - 2nd Note that are to be placed on the same page. are to be placed on the same page.
Disposition: Explanation of why no change will be made
Proposed change would change intention of sentence.
6.4.13 Areas - last Note "rl-tb"writing-mode. "rl-tb" writing-mode.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.4.13, 6.4.14, 6.4.15, 6.4.16 and 6.4.17 Trait Derivation - par. 1 value the reference-orientation trait value of the reference-orientation trait
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.
6.4.14, 6.4.15, 6.4.16, and 6.4.17 Areas - last par. to to to
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.
6.6.1.1.2, 6.6.1.1.3, and 6.7.1.1.1 Example result instance, and the
stylesheet in 6.9.1.1.2
[Given the left margin, the longest line can run out the right side
of a full screen window at 640x480. Possibly there is another way to
break lines, for example:]
</fo:initial-property-set>This is the text of a paragraph that
is going to be presented with the first line in small-caps.
Disposition: Explanation of why no change will be made
Many of the graphics are quite detailed and are not usable at a dpi value which would make them fit on a 640 wide screen. Thus we are not targeting this, by now rather obsolete, screen size for the spec.
6.6.3 par. 3 semantic... are [can be "semantics... are" or "semantics... is"]
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.6.11 Constraints - par. 3 objects; one for objects, one for
Disposition: Explanation of why no change will be made
6.8.1 - par. 1 after illustration role of containing the complete list and to specify values role of containing the complete list and of specifying values
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.8.1 - par. 4 after illustration ding-bat dingbat [It's a dictionary word.]
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.8.1.1.1 example [You might keep the same order as the other examples: input, stylesheet, result.]
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.8.1.1.2 example [You might keep the same order as the other examples: input, stylesheet, result.]
Disposition: Explanation of why no change will be made
The result in this case is part of the discussion of what the example is intending to do (always at the start of the example) and needs to be consulted in conjunction with this description.
6.10.1.1 par. 1 First, so that during First, during [?]
Disposition: Explanation of why no change will be made
We feel that the original wording reads better.
6.10.3 Constraints - par. 2 "region-reference-area "region-reference-area"
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.2 last par. values in[5 values in [5
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.4.1 - fixed the top the viewport the top of the viewport
Disposition: Accepted (editorial)
This is an XSL derived property, but even though the text is copied from CSS the XSL WG decided to make this editorial change.
Links to the changed text in the XSL recommendation:
See link to changed text.
7.4.1 last line posiiton position
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.6.9, 7.6.12, 7.6.31, and 7.6.32 - <length-conditional> it's its
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.
7.7.1 - <family-name> In the previous example [There's no example. Omit, say "[In the example given in CSS2]", or give example.]
Disposition: Accepted (editorial)
This text is copied from CSS. It was decided to add "[in the CSS2 spec]" to the text rather than making and "xsl-mod".
Links to the changed text in the XSL recommendation:
See link to changed text.
7.7.3 Value ultra-expanded |inherit ultra-expanded | inherit
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.7.3 Value [Also, in this property definition, the 'font-stretch' keywords are listed three times. To cut repetition, maybe the uncommented list could be omitted.]
Disposition: Explanation of why no change will be made
Listing enumerated values in bold is consistently done throughout the specification. We feel that, even though it is repetitious, consistency is preferable.
7.8.1 last line code (these code; (these
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.8.5 Initial unicode Unicode
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.9.3 and 7.9.4 - <percentage>
"...This is true for 'margin-top' and 'margin-bottom', except
in the page context, where percentages refer to page box
height."
[Can this sentence be omitted for 'margin-left' and 'margin-right'?]
Disposition: Accepted (editorial)
This is modified CSS text so we can change it.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
7.11.6 - before and baseline par. 1, and baseline par. after Note at least, one at least one
Disposition: Explanation of why no change will be made
7.12.1 - <length-range> created, if minimum created; if minimum
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.12.4 par. 3 non replaced non-replaced
Disposition: Accepted (editorial)
This text is WRONGLY copied from CSS.
Links to the changed text in the XSL recommendation:
See link to changed text.
7.12.6 and 7.12.7 These two properties allow [It may be unclear that this means 'max-height' and 'max-width'. Could mention their names.]
Disposition: Accepted (editorial)
This text is copied from CSS. It was decided to add '["max-height" and "max-width"]' to the text rather than making and "xsl-mod".
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
7.14.3 auto codepoints codepoint
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.14.6 ([RFC2070]) [Needs a link to http://www.w3.org/TR/xsl/sliceD.html#RFC2070]
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.18.2 - XSL - auto if the User Agent if the User Agent if the user agent
Disposition: Explanation of why no change will be made
This value is being removed so the comment no longer applies.
7.19.5 groove and ridge , the other half ; the other half
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
7.20.1 active user. For example, user, for example,
Disposition: Explanation of why no change will be made
We do not want to mix normative and non-normative text in the same sentence.
7.21 Note when several nested fo:multi-switch objects builds when several nested fo:multi-switch objects build
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.30 - last par. of xsl-preceding and xsl-following It the current If the current
Disposition: Accepted (editorial)
Note that this occurs TWICE in the text.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
7.32.1, 7.32.2, 7.32.3, and 7.32.4 This property is defined in XSLT: Number to String Conversion Attributes. [Needs XSLT section number (7.7.1) and link to XSLT in References.]
Disposition: Accepted (editorial)
It is accepted to add a link. Since the section number may change for XSLT 2.0 that part of the comment is rejected.
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.
7.34.6 - last par. &
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.35.1 - last par. of CSS2 [HTML40] [HTML4] or [HTML4.01] [and needs an entry in References]
Disposition: Explanation of why no change will be made
This is text quoted from CSS2.
7.35.6 - XSL 1st par. The phasing The phrasing
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.36.8 - last par. Changed initial value to visible (is "inherit" in CSS). Changed initial value to visible; (it is "inherit" in CSS).
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
D.1 ICC. [I would spell that out: "International Color Consortium."]
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
[1] http://www.w3.org/TR/2000/WD-xsl-20000327/ Best wishes for your project, -- Susan Lesch Intern, W3C
From: alrb@us.ibm.com To: xsl-editors@w3.org Message-ID: <852568CD.00543D60.00@D51MTA08.pok.ibm.com> Date: Wed, 26 Apr 2000 11:20:00 -0400 Subject: fo:inline-container
The "trait derivation" section of 6.6.8 needs to be expanded to contain an explicit description on how the "externally visible" baseline (that is used for placing the area(s) generated by this FO) is determined.
Disposition: Accepted (bug in spec)
Links to the changed text in the XSL recommendation:
See link to changed text.
Submitter's acceptance of disposition:
From: alrb@us.ibm.com To: xsl-editors@w3.org Message-ID: <852568F1.0062D424.00@D51MTA03.pok.ibm.com> Date: Thu, 1 Jun 2000 13:59:29 -0400 Subject: Disposition of my comments I accept the disposition of the comments I made on the XSL last call draft archived under: Comment 12: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0031.html Comment 16: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0036.html Comment 19: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0039.html Anders Berglund
Message-Id: <3.0.5.32.20000426101518.012b8e60@mail-321> Date: Wed, 26 Apr 2000 10:15:18 -0700 To: xsl-editors@w3.org, w3c-xsl-fo-sg@w3.org From: Stephen Deach <sdeach@Adobe.COM> Subject: RE: number questions
This question came up on the public list WRT XSLT, but the same issue applies to XSL-FO. We should review this in the meeting next week. >From: Kay Michael <Michael.Kay@icl.com> >To: "'xsl-list@mulberrytech.com'" <xsl-list@mulberrytech.com> >Subject: RE: number questions >Date: Wed, 26 Apr 2000 09:20:33 +0100 >X-Mailer: Internet Mail Service (5.5.2650.21) >Sender: owner-xsl-list@mulberrytech.com >Reply-To: xsl-list@mulberrytech.com > >The answers I reached when I asked myself the same questions for Saxon were: > >> 1. What should be output from the following stylesheet >> fragment, assuming >> that "unknown" is not an element in the current stylesheet: >> >> <xsl:number count="unknown" level="any" format="1."/> >> >The number to be output is zero. The way non-positive numbers are formatted >is not defined by the spec, so I ignore the format attribute and just use >the same conversion as the string() function. > >> when level="any" and no matches are >> found, the spec doesn't say an empty list should be returned. >> Is this an oversight, or should 0 be returned? > >It may be an oversight, but whether intentional or not the rules clearly say >the answer is zero. >> >> 2. If an empty list should be returned, then should any >> format tokens (such as the ".") be output? > >Again the rules here are clear, the output should be ".". > >> >> 3. How about negative numbers: >> >> <xsl:number value="-1" format = "1."/> >> >The rules here are undefined, I ignore the format and display the answer >using string(). > >Mike Kay > > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > >
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0033.html
Message-ID: <390724E9.F3121C20@eng.sun.com> Date: Wed, 26 Apr 2000 10:18:33 -0700 From: Eduardo Gutentag <eduardo.gutentag@eng.sun.com> To: Stephen Deach <sdeach@adobe.com> CC: xsl-editors@w3.org, w3c-xsl-fo-sg@w3.org Subject: Re: number questions Stephen Deach wrote: > > This question came up on the public list WRT XSLT, but the same issue > applies to XSL-FO. We should review this in the meeting next week. Steve, I'm not sure I understand why this applies to XSL-FO. Isn't the issue of what xsl:number returns in these conditions an XSLT matter only? Eduardo -- Eduardo Gutentag | e-mail: eduardo@eng.Sun.COM XML Technology Center | Phone: (650) 786-5498 Sun Microsystems Inc. | fax: (650) 786-5727
Disposition: Explanation of why no change will be made
This comment does not apply to XSL FOs; only to XSLT. It is only used for page numbers and these cannot be 0 or negative.
-----------------------------------------------------------------------------
This e-mail reflects the personal opinion of the author.
-- Unless explicitly so stated in the text, it does not represent an
official position of Adobe Systems, Inc.
-- Unless explicitly so stated in the text, it does not represent an
official opinion of the W3C XSL Working group.
-----------------------------------------------------------------------------
Stephen Deach | Sr Computer Scientist
408-536-6521 (office) | Adobe Systems Inc.
408-537-4214 (fax) | Mail Stop W15-424
sdeach@adobe.com (no ads) | 345 Park Ave
| San Jose, CA 95110-2704
| USA
----------------------------------------------------------------------------
Message-ID: <39076487.5DF91886@club-internet.fr> Date: Wed, 26 Apr 2000 23:49:59 +0200 From: Karen Lease <klease@club-internet.fr> To: xsl-editors@w3.org Subject: Table areas Hello, I've (finally) been reading the latest XSL spec. I've got a few questions or requests for clarification concerning the areas generated by the fo:table objects.
Question 1. In 6.7.3 the spec says: "The fo:table formatting object generates one or more normal block-areas." Under the "Trait derivation" section it says, "The areas generated by the fo:table formatting object have a value of "true" for the is-reference-area." Does that mean that the area(s) generated by fo:table are really normal "reference-areas"? That seems more consistent with other parts of the spec (fo:table-cell and fo:table-caption for example.) Or perhaps table areas are NOT intended to be reference areas. This actually seems more reasonable to me, since cells are reference areas.
Disposition: Accepted (clarification)
What the text intends to say is that the top level areas that the fo:table generates and returns are: normal, block-level, and reference areas. All areas to which writing-mode applies are reference areas, so this is the reason why they are reference areas. The child areas with background only are not reference areas. The text needs some updating to make this clear.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
Question 2. Also in 6.7.3, the spec says: "The areas generated by the fo:table formatting object have as children: . Areas, with only background, corresponding to the column-groups, columns, and rows. . Areas returned by the fo:table-cell formatting objects." But in the sections concerning columns and rows, it clearly says that these FOs don't directly generate any areas. I interpret this to mean that any background (and border?) properties specified on columns or rows affect the appearance of the underlying table grid (as determined by the z-order). But perhaps this could be made clearer?
Disposition: Accepted (clarification)
You are correct in your assumptions regarding the "background". The text will be updated to make this clear.
For "border"s see the follow-up posting.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
Thanks in advance for any explanations, Karen Lease
Message-Id: <3.0.32.20000426175640.0074fad0@pophost.arbortext.com> Date: Wed, 26 Apr 2000 17:56:47 -0500 To: xsl-editors@w3.org From: Paul Grosso <pgrosso@arbortext.com> Subject: comments on the XSL draft of 27 March 2000
1. The diagram at the end of 1.1 says "syntactically, [Result XML] is XML elements and attributes." This isn't accurate, as Result XML needn't syntactically be anything, it is a tree (or infoset) of objects. I suggest removing that whole sentence from the box in the graphic since it is erroneous and unnecessary given that the immediately following paragraph describes the result tree in proper terms.
Disposition: Accepted (bug in spec)
Links to the changed text in the XSL recommendation:
See link to changed text.
2. The last diagram in 1.1.2 shows the generation of the area tree, but the arrow between the two trees is labelled "XSL Formatting Area Tree". Instead, it should just be labelled "XSL Formatting Area Tree Generation" or something, because the process isn't the area tree, it produces the Area tree.
Disposition: Accepted (bug in spec)
Links to the changed text in the XSL recommendation:
See link to changed text.
3. In 1.2.1 Paging and Scrolling, in the para talking about the splitting up of the white-space property, it talks about a "line-feed" property that should be "linefeed-treatment".
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
4. In 3 Introduction to Formatting, second para, it says: "...traits, which are to areas what properties are to formatting objects and attributes are to XML nodes." I think the last word should be "elements", not "nodes" for the analogy to be in its clearest form. For example, note in section 4.1 we say "Each area has a set of traits, a mapping of names to values, in the way elements have attributes and formatting objects have properties."
Disposition: Accepted (clarification)
Links to the changed text in the XSL recommendation:
See link to changed text.
5. In 4.1, the para after the first graphic, there is a sentence that reads in part "Traits whose values are copied from property of the same or a corresponding name are listed in [C Property Index]...." There appears to be a missing word in "copied from property".
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6. In 4.3 Spaces and Conditionality, the first sentence lists the components of a space specifier as "minimum, optimum, and maximum, conditionality, and precedence." The "and" between optimum and maximum shouldn't be there, and may lead to confusion.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7. In 4.3.1 Space-resolution Rules, the second para of point 3, starts "Otherwise, when there are at two or more space-specifiers all of the same highest precedence...." I think "there are at two or more" should instead read "there are two or more" (delete "at"). Also, the example in that section starts with "Example. Suppose the sequence of space values occurring at the beginning of a reference-areas is:" That should be "of a reference area is" (reference-area shouldn't be pluralized). The penultimate paragraph of this section starts with "The padding of a block-area does not interact with the any space-specifier...." Problem with "the any".
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.
8. In 4.3.1 Space-resolution Rules, I don't see (except where it is implied in the example) where it is said how the conditionality of the resolved space is determined or even if resolve space should have conditionality (since conditionality is really only relevant in the resolution process). Something needs to be said about this.
Disposition: Accepted (clarification)
We have reinterpreted the comment to refer to precedence rather than conditionality.
Links to the changed text in the XSL recommendation:
See link to changed text.
9. In 5.1.2, the penultimate sentence reads: However, there are some properties whose specified value may be inherited (e.g., the value for the "line-height" property). But this is not true for all values of the line-height property, only in the case where the value is a unitless number (giving a factor by which to multiple the font size). So I suggest this be reworded as follows: However, there are some properties whose specified value may be inherited (e.g., some values for the "line-height" property).
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
10. Twice in 5.3 and once in 5.3.1, "correspondance" ->
"correspondence" (spello).
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.
11. In 5.8.11 Lexical Structure, the first bullet point reads:
If the character following an NCName (possibly after
intervening ExprWhitespace ) is "(", then the token
must be recognized as FunctionName.
I would rather we deleted the parenthetical phrase. In
most programming languages and other notations, if one puts
whitespace between the name and the open paren, it is no
longer recognized as a function call, and I think this
behavior is more common and makes more sense and is more
in keeping with the analogous case of putting space around
minus (-) signs to avoid them being considered part of a
name and requiring no space between numbers and unitnames.
Disposition: Explanation of why no change will be made
This part of the lexical structure is copied from Xpath 3.7 and we should be consistent with that Recommendation.
12. Also in 5.8.11, last bullet point includes the word "numeric" but fails to tag it correctly. Since it is important here that "Numeric" (uppercase N) refers to the token in production 5 of our expression language, this needs to be retagged appropriately.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
13. In 5.9.4 Property Value Functions, the
inherited-property-value function returns the inherited
value of the given property. I'd like to make it clearer
just what is the inherited value. I suggest the following
wording and example:
The returned "inherited value" is the computed value
of this property on this objects parent. In particular,
given the following example:
<fo:list-block>
<fo:list-item color="red">
<fo:list-item-body background-color="green">
<fo:block background-color=inherited-property-value(color)>
</fo:block>
</fo:list-item-body>
</fo:list-item>
</fo:list-block>
The background-color property on the fo:block is assigned
the value "red" because the (computed, after inheritance)
value of the color (not background-color) property on the
fo:block that is the parent of fo:inline is "red".
Disposition: Accepted (clarification)
Links to the changed text in the XSL recommendation:
See link to changed text.
14. In 5.9.4 Property Value Functions, under the proportional-column-width writeup, it says that "function returns proportional factor (the argument) units of proportional measure." Im having a bit of trouble parsing that sentence. I assume we're just saying that the function returns N units of proportional measure where N is the argument given to this function, and I would prefer some such wording.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
15. In 5.9.4 with respect to proportional-column-width, we say that it is an "error to use this function on formatting objects other than an fo:table-column" but I don't see why we don't allow the use of this function anywhere within a table. For example, why couldn't someone want to set, say, indents within a table cell to some fraction of the proportional-column-width? Or perhaps make use of the proportional-column-width in an xsl-if test to decide what font-size to use somewhere or make some other decision? I'm not suggesting we allow the * syntax elsewhere, but since an implementor has to implement the proportional-column-width function and handle it when it is given within an expression in an attribute value on the fo:table-column FO, what's so hard about allowing that function in other expressions within the table. It sort of seemed like it might be more work to forbid such use than just allow it, and some users might find it useful.
Disposition: Explanation of why no change will be made
The definition of the "proportional-column-width" function specifies how you compute the value of "1*". The design is such that it is only used in places where it is used in BOTH the INPUT (to be used in the calculation of a value for "1*") and REFER (getting an actual width value once a value for "1*" has been determined) sense. It was concluded that it would be rather confusing if you could use the function on fo:table-column and also eg in an expression for start-indent="proportional-column-width(20)" and find that this 20* is less than the column width.... whereas if specified on the table-column an effort is made to ensure that the value is honored...
There is also some concern about ambiguity in the case of nested tables.
16. In 5.10 Property Datatypes, the last sentence of the
second para reads (typo):
For example a the "space-before" property may be specified as:
^^^^^
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
17. In 5.10 Property Datatypes, under the description of the short form, we say: Such a specification gives that value to each of the numeric components and the initial value to all the non-numeric components. But space-before.precedence is a numeric component, yet we want to use the initial value, not the given value, in this case. Therefore, instead of: A short form of compound value specification may be used, in cases where the datatype has some numeric components. Such a specification consists of giving a numeric value to an attribute with a name matching a property name. Such a specification gives that value to each of the numeric components and the initial value to all the non-numeric components. I suggest: A short form of compound value specification may be used in some cases. Such a specification consists of giving a single value to an attribute with a name matching a property name. Such a specification gives that value to some of the components and the initial value to other components. Each property description describes any allowable short form and how it affects that compound property.
Disposition: Accepted (bug in spec)
It was decided to only permit lengths as the value of short forms, which removes the ambiguity. We do not want to describe short forms (potentially differenctly) for each property.
Links to the changed text in the XSL recommendation:
See link to changed text.
18. In 5.10, our defn of the <name> datatype reads: A string of characters representing a name. It must not contain any whitespace, or space characters. First, saying whitespace or space characters seems odd/redundant. Second, is this really a proper defn? Aren't there lots of other characters that cannot be in a name?
Disposition: Accepted (bug in spec)
To be defined as an NCname in accordance with the XML recommendation.
Links to the changed text in the XSL recommendation:
See link to changed text.
19. In section 5.10 we define the datatype <uri> as: A sequence of characters conforming to a URI value as specified in the URI specification. but this is ambiguous and does not use standard terminology. I suggest we change it to read: A sequence of characters conforming to a relativeURI value as specified in [RFC 2396]. The term "relativeURI" is defined in section 5 of RFC2396. This would allow relative URIs without allowing fragment identifiers. Note that the <uri> datatype is used in XSL in section 7.36.7 as the type of the "src" property, and note that the <IMG> element's src attribute in HTML clearly allows relative URIs; see Section 6.4 URIs of the HTML 4.01 spec http://www.w3.org/TR/html401/types.html#type-uri which says: Relative URIs are resolved to full URIs using a base URI. [RFC1808], section 3, defines the normative algorithm for this process. (but note that RFC 2396 supercedes RFC 1808 now).
Disposition: Accepted (bug in spec)
After review it was decided that all uses in XSL should be changed to uri-references (i.e. in all cases permit fragment identifiers).
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.
20. In the third from last para of "6.1.1 Definitions
Common to Many Formatting Objects", there is a typo:
Out-of-line areas are areas used outside the normal
flow of text either because the are absolutely positioned
^^^
they
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
21. At the end of 6.2, we say (about float and footnote): The following "out-of-line" formatting objects may be used anywhere where #PCDATA, %block;, or %inline; are allowed: We should make this more accurate by appending: (except as a descendant of any "out-of-line" formatting objects)
Disposition: Accepted (clarification)
Links to the changed text in the XSL recommendation:
See link to changed text.
22. In 6.3, we say:
multi-switch The fo:multi-switch is used to switch
between two or more sub-trees of formatting objects.
This is not as clear as possible given the role of
fo:multi-toggle in switching from one fo:multi-case to
another. Maybe a better wording would be:
multi-switch The fo:multi-switch wraps the specification
of alternative sub-trees (each within an fo:multi-case)
of formatting objects and controls the switching (activated
via fo:multi-toggle) from one alternative to another.
Disposition: Accepted (clarification)
Change the wording to:
The fo:multi-switch wraps the specification of alternative sub-trees of formatting objects (each sub-tree being within an fo:multi-case), and controls the switching (activated via fo:multi-toggle) from one alternative to another.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
23. In 6.3, we describe multi-case as:
multi-case The fo:multi-case is used to embed flow
objects, that the parent fo:multi-switch can choose
to either show or hide.
But that makes it sound like a multi-switch could show
3 cases and hide 4 which is not the case. Suggestion:
multi-case The fo:multi-case is used to contain
(within an fo:multi-switch) each alternative
sub-tree of formatting objects among which the
parent fo:multi-switch will choose one to show.
Disposition: Accepted (clarification)
Change the wording to:
The fo:multi-case is used to contain (within an fo:multi-switch) each alternative sub-tee of formatting objects among which the parent fo:multi-switch will choose one to show and will hide the rest.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
24. In 6.3, our current description of table-caption reads:
table-caption The fo:table-caption formatting object
is used to contain block-level formatting objects
containing the caption for the table.
As written, I fear people will think they must use this
FO to get a caption on any table; however, in fact this
FO is only allowed within fo:table-and-caption. Therefore,
I think it would clear things up to augment the description
to read as follows:
table-caption The fo:table-caption formatting object
is used to contain block-level formatting objects
containing the caption for the table when using the
fo:table-and-caption.
Disposition: Accepted (clarification)
Change the wording to:
The fo:table-caption formatting object is used to contain block-level formatting objects containing the caption for the table only when using the fo:table-and-caption.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
25. In 6.4.1.2 Page-masters, second para (typo): The page-viewport-area is defined by the output medium; the page-area holds the page contents and has the affect of positioning the page contents on the output medium. Change "affect" (which is a verb) to "effect" (which is the noun).
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
26. In 6.4.10 fo:repeatable-page-master-alternatives, the last sentence before "Contents" reads: If the conditions on all alternatives to extend a sub-sequence are false, then the sub-sequence may not be extended. I have no idea what this means, and a search for the word "extend" in what seemed like a similar context failed. This needs to be reworded to avoid the word "extend" or to explain what it means.
Disposition: Accepted (clarification)
This sentence was removed as it did not clarify the intent of the previous paragraph.
Links to the changed text in the XSL recommendation:
See link to changed text.
27. The example in 6.5.1.1.1 Chapter and Section Titles, Paragraphs isn't quite right. The input file and stylesheet don't really quite generate the result tree shown, and the input file isn't right for the discussion about spacing that follows it (e.g., "Space between the second paragraph of the first section and the title of the second section...", but the input file shown has two chapters but never two paragraphs in one section). I've attached an HTML version of a corrected section 6.5.1.1.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
28. In 6.2, under Trait derivation, we say "The half-leading trait is set to 1/2 the computed value of the line-height property minus the font-size property." The "implicit parens" in that mathematical expression are ambiguous. I suggest instead "The half-leading trait is set to 1/2 the difference of the computed value of the line-height property and the font-size property."
Disposition: Accepted (clarification)
Links to the changed text in the XSL recommendation:
See link to changed text.
29. In 6.6.5 fo:external-graphic, under common usage, we say "The fo:external-graphic flow object is used for an inline graphic where the graphics data resides outside of the fo:element tree." I'm not sure what to suggest, but the use of the term "inline graphic" in this sentence can be confusing, since we're talking about external graphics (residing outside the tree). The problem is that there are two uses of the term "inline", but I fear some readers will get confused by "external inline graphics". Maybe even just saying "inline-level graphic" if that works, or something else--I don't know.
Disposition: Accepted (editorial)
"inline" to be removed from the sentence.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
30. In 6.6.5, we don't mention about wrapping fo:external-graphic in fo:block to produce a display graphic (though we do have such an example)--we do say the analogous thing for leaders and simple-links and such, so I recommend we add a Note saying: An fo:external-graphic can be wrapped in an fo:block to create a display graphic.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
31. In 6.6.6 fo:instream-foreign-object, under Constraints, we say "See [6.6.5 fo:external-graphic]", but then under Contents, we repeat all of what was under Constraints in 6.6.5. I think what should be done is to move the 3rd para onwards from contents to constraints and to remove the reference to 6.6.5.
Disposition: Accepted (editorial)
The 3rd para onwards shold be moved from contents to constraints and the reference to 6.6.5 removed. (there is slight, but important, rewording between the two constraints...
Links to the changed text in the XSL recommendation:
See link to changed text.
32. In 6.7.3 fo:table we say: inline-progression-dimension="auto" table-layout="fixed" The automatic table layout shall be used. This has been the discussion of some email from Norm et al. This has to change to say "The fixed table layout shall be used" to make sense and for CALS tables to work. It is an absolute requirement for me that XSL support the composition of CALS/OASIS Exchange tables.
Disposition: Accepted (clarification)
The follwing text will be added to the note regarding the restrictions of the use of "proportional" widths:
If the use of proportional column widths are desired on a table of an unknown explicit width, the inline-progression-dimension cannot be specified to be "auto". Instead, the width must be specified as a percentage. For example, setting table-layout="fixed" and inline-progression-dimension="100%" would allow proportional column widths while simultaneously creating a table as wide as possible in the current context.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
33. In 6.7.5 fo:table-caption, I have the same comment here as
I did in comment 20 above. We should reword the common usage
to read:
The fo:table-caption formatting object
is used to contain block-level formatting objects
containing the caption for the table when using
the fo:table-and-caption.
Disposition: Accepted (editorial)
Same as item 24 (text copied). See disposition of that item.
34. In 6.7.10 fo:table-cell, I was surprised not to see any discussion of starts-row and ends-row. I realize these are properties and, as such, are discussed in section 7, but I think some mention of them in this section would be helpful.
Disposition: Accepted (editorial)
Text has been added to "common usage".
Links to the changed text in the XSL recommendation:
See link to changed text.
35. In 6.8.1.1.1 Numbered List, the second para says: The style is to number the items alphabetically with a dot at the end of the number. however, I think most people will be confused by the phrase "numbered alphabetically" (I know I was). An acceptable phrase would be "enumerated alphabetically", so I suggest changing the sub-section title to "6.8.1.1.1 Enumerated List" and the second para to "The style is to enumerate the items alphabetically with a dot at the end of the letter."
Disposition: Accepted (editorial)
Proposed text accepted.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
36. In 6.9.1.1.2 Expandable/Collapsible Table of Contents, the input example includes: xlink:href="http://w3.org/TR" which has the wrong URL for the purposes described. Although it is just an example, it would be best to correct it to read: xlink:href="http://www.w3.org/TR" Likewise later in the XSL stylesheet for the same example and in the result instance (total of 3 occurrences).
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.
37. In 6.9.2 fo:simple-link, the note reads: An fo:simple-link may be displayed by enclosing it in an fo:block. I fear the phrase "be displayed" is easily misinterpreted, so it might be better to reword this to be something more like: An fo:simple-link can be wrapped in an fo:block to create a display area. (which is a bit more like what we said for fo:leader).
Disposition: Accepted (editorial)
Accepted, but using "enclosed" rather than "wrapped".
Links to the changed text in the XSL recommendation:
See link to changed text.
38. In 6.9.3 fo:multi-switch, under Trait derivation, we say: The currently-visible-multi-case trait has as initial value a reference to the first fo:multi-case child that has a value of "show" of the starting-state trait. If there is no such child, it has a value indicating that there is no currently visible fo:multi-case. The trait value may be changed by actuating an fo:multi-toggle. My question is, if there is no multi-case child showing at all, then how can one actuate any fo:multi-toggle, as it seems to say with the last two sentences above. I suggest the following rewording: The currently-visible-multi-case trait has as initial value a reference to the first fo:multi-case child that has a value of "show" of the starting-state trait; if there is no such child, the trait takes on a value indicating that there is no currently visible fo:multi-case. When any fo:multi-toggle that is a child of this fo:multi-switch is actuated, this fo:multi-switch's currently-visible-multi-case trait value changes to refer to the fo:multi-case referred to by the actuated fo:multi-toggle's switch-to trait.
Disposition: Accepted (clarification)
Rewording:
The currently-visible-multi-case trait has as its initial value a reference to the first fo:multi-case child that has a value of "show" of the starting-state trait. If there is no such child, it has a value indicating that there is no currently visible fo:multi-case. When an fo:multi-toggle is actuated, its closest ancestral fo:multi-switch's currently-visible-multi-case trait value changes to refer to the fo:multi-case selected by the "switch-to" property value of the fo:multi-toggle. Once the currently-visible-multi-case trait gets a value indicating that there is no currently visible fo:multi-case, it becomes impossible to actuate an fo:multi-toggle in this fo:multi-switch.
Links to the changed text in the XSL recommendation:
See link to changed text.
39. In 6.9.5 fo:multi-toggle (under constraints) we say: Activating an area returned by an fo:multi-toggle causes a change to the value of the currently-visible-multi-case of the closest fo:multi-switch. I think we should be more specific and say something like: Activating an area returned by an fo:multi-toggle causes the value of the currently-visible-multi-case trait of the parent fo:multi-switch to refer to the fo:multi-case selected via this fo:multi-toggle's switch-to trait. (See [7.30 "switch-to"] for how the switch-to value selects an fo:multi-case.)
Disposition: Accepted (editorial)
It was decided to keep the original text and add the "(see ... case.)" text.
Links to the changed text in the XSL recommendation:
See link to changed text.
40. In 6.11.3 fo:marker, we don't say that fo:marker has to be an initial child of its parent. We mention this everywhere else we talk about fo:marker, but it seems worth mentioning it in this section too.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
41. In 7.3.1 "source-document" we say the value is: A list of space-separated URIs, indicating the XML document(s) used as input to the stylesheet. and add: This property provides a pointer back to the original XML document(s) used to create this formatting object tree. The "applies to" says "see prose", but I don't see in the prose where we say anything about what FOs it applies to (I assume it could apply to any FO). I have two concerns: (1) that this wording will imply that there is special XSL semantics with this value, either in terms of automatically setting a value for this property or in terms of validating the value, and (2) that the "pointer back" wording combined with "URI" will leave some readers thinking that this points back to the source element as opposed to the source document. In fact, although we say that this value is a URI, and not a URI reference. So I'd like to see some added wording such as: This property can be used by the stylesheet writer to provide a pointer back to the original XML document(s) used to create this formatting object tree, but that this is not validated by and has no inherent standardized semantics for any XSL processor.
Disposition: Accepted (clarification)
The suggested added wording has been included and the "see prose" text from the "role" property included.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
42. In 7.6.2 "background-color", we say that XSL adds icc-color as a value of this property, but then there is no link to more discussion, and it seems there should be one to 5.9.2 Color Functions.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
43. In 7.13.1 "hyphenation-keep", we list the initial value as "none", but that's not a value choice--I think we mean "auto" here.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
44. In 7.13.10 "text-align-last", the value <string> says it: applies only to table cells. If set on other elements, it will be treated as "start". This isn't right, and in fact, I don't believe the <string> value is well defined or necessary, and I suggest we remove it from this property.
Disposition: Accepted (bug in spec)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
45. In 7.15.1 "color", we mention icc-color, but don't include a "see also" link there to 5.9.2 Color Functions as we probably should.
Disposition: Accepted (editorial)
This change is also being made in 6.4.4 fo:color-profile.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
46. In 7.30 "switch-to", under xsl-preceding, we say: Activating the switch should result in that the current fo:multi-case is replaced by its preceding sibling. Odd wording there "should result in that"? Also, the last sentence here just before xsl-following starts with "It" when it should start with "If". Also, the same two comments apply to the xsl-following description.
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.
47. In 7.34.6 "empty-cells", near the bottom of the CSS box, there is a mention of & where two &'s show--typo.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
48. In 7.36.6 "score-spaces", both "applies to" and "percentages" says "see prose", but there is nothing in the prose.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
From: alrb@us.ibm.com To: xsl-editors@w3.org Message-ID: <852568CE.0057D04D.00@D51MTA08.pok.ibm.com> Date: Thu, 27 Apr 2000 11:59:02 -0400 Subject: borders on fo:table-cell
Section 6.7.10 refers to a priority for borders on table cells that is used in disambiguating which border specification is used (in the border-collapse=collapse case), but there seems to be no wayt of setting these priorities.
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0037.html
Message-ID: <3908ADBF.9DCD0D6A@club-internet.fr> Date: Thu, 27 Apr 2000 23:14:39 +0200 From: Karen Lease <klease@club-internet.fr> To: xsl-editors@w3.org Subject: Re: borders on fo:table-cell alrb@us.ibm.com wrote (26 april) > > Section 6.7.10 refers to a priority for borders on table cells that is used > in disambiguating which border specification is used (in the > border-collapse=collapse case), but there seems to be no wayt of setting > these priorities. Yes, I just noticed this too. I believe this is a hold-over from the DSSSL way of specifying borders on table objects. It would only seem to be a problem when border-collapse=collapse. Then the border from adjacent cells could be in conflict. ... (see 2000AprJun/0037.html comment for the rest of the message)
Disposition: Accepted (bug in spec)
Four new properties border-x-precedence have been added.
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.
Submitter's acceptance of disposition:
From: alrb@us.ibm.com To: xsl-editors@w3.org Message-ID: <852568F1.0062D424.00@D51MTA03.pok.ibm.com> Date: Thu, 1 Jun 2000 13:59:29 -0400 Subject: Disposition of my comments I accept the disposition of the comments I made on the XSL last call draft archived under: Comment 12: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0031.html Comment 16: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0036.html Comment 19: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0039.html Anders Berglund
Message-ID: <3908ADBF.9DCD0D6A@club-internet.fr> Date: Thu, 27 Apr 2000 23:14:39 +0200 From: Karen Lease <klease@club-internet.fr> To: xsl-editors@w3.org Subject: Re: borders on fo:table-cell ... (this part moved to discussion of 2000AprJun/0036.html)
I am assuming that there is no conflict between "cell borders" and "row or column or table borders", since the spec says (7.34.2): "Rows, columns, row groups, and column groups cannot have borders (i.e., user agents must ignore the border properties for those elements)." I interpret this to mean that any borders specified on those objects only serve to provide inherited values to cells which don't explicitly specify a value, but are not to be rendered, so they can't be in conflict. (In fact, there are no row or column "areas" on which to apply the traits, so they can only be propagated to the cell areas.)
Disposition: Accepted (clarification)
These properties are not inherited. More explanation will be added in the formatting object description to point out that the borders specified on table-column and table-row are not used.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
-Karen
To: xsl-editor@w3.org Message-Id: <20000429012727I.next@tom.sfc.keio.ac.jp> Date: Sat, 29 Apr 2000 01:27:27 +0900 From: Norio Touyama <next@tom.sfc.keio.ac.jp> Subject: Question on border-widths Hi XSL editors. I have question about "border-width" property treatment.
"border-*-width" are described as it's Intial vaule are medium. In my understanding, it's reasonable for block-areas. But I'm not sure about treatment for inline-areas or stacked areas. Why is it's inital value not zero?
Disposition: Explanation of XSL spec
It is "medium" for CSS compatibility. Note, however, that "effectively" the initial value is 0pt, since the border-*-style initial values are "none" which forces a value of 0pt for the width (see 7.6.9, 7.6.12, 7.6.15, 7.6.18)
If we use stacked inline-areas without specific border-width,
should these borders be summed up simply?
e.g, ----
<block>start<inline>foo<inline>bar<inline>foo2</inline></inline></inline>end</block>
Should this fo be renderd to like below?
(please assume "|", "+" and "-" as medium-size border)
+---+---+----+++
| +---+----+++
| | +----+++
start|foo|bar|foo2|||end
| | +----+++
| +---+----+++
+---+---+----+++
Disposition: Explanation of XSL spec
Yes they are all displayed on a common edge. Your drawing is correct IF we assume that the border has a non-zero width (and a style that does not force the width to be zero).
---- mailto:next@tom.sfc.keio.ac.jp TOUYAMA Norio
From: alrb@us.ibm.com To: xsl-editors@w3.org Message-ID: <852568CF.0065B78D.00@D51MTA08.pok.ibm.com> Date: Fri, 28 Apr 2000 14:30:53 -0400 Subject: fo:instream-foreign-object
The second sentence in the second paragraph under "contents" needs to have the following text added before the second word: ", as well as the xsl properties, " to reflect the agreed semantics of this interface.
Disposition: Accepted (clarification)
The text will be added.
Links to the changed text in the XSL recommendation:
See link to changed text.
Submitter's acceptance of disposition:
From: alrb@us.ibm.com To: xsl-editors@w3.org Message-ID: <852568F1.0062D424.00@D51MTA03.pok.ibm.com> Date: Thu, 1 Jun 2000 13:59:29 -0400 Subject: Disposition of my comments I accept the disposition of the comments I made on the XSL last call draft archived under: Comment 12: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0031.html Comment 16: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0036.html Comment 19: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0039.html Anders Berglund
To: xsl-editors@w3.org Cc: timbl@w3.org From: H嫯n Wium Lie <howcome@opera.com> Message-Id: <E12ltMQ-0006et-00.2000-04-30-14-02-10@mail5.svr.pol.co.uk> Date: Sun, 30 Apr 2000 14:02:10 +0100 Subject: Last call, XSL 1.0 This message is sent in reply to the last call for comments for XSL 1.0 and represents Opera Software's views. This is the second specification coming out of the XSL WG. The first one, a transformation language known as XSLT, has already become a W3C Recommendation and now the group proposes a syntax for "formatting objects" written in XML (called XSL-FO in this message).
The formatting objects contain information about how a document is to be presented. Also, they contain hyperlink information. A document written in XSL-FO is therefore at the same level of abstraction as an HTML document consisting of presentational elements (e.g. FONT and BR) and A elements. Indeed, many pages on the web only consist of presentational elements and links. These pages have been considered a threat to accessibility and device-independence in the past, and W3C has spent considerable efforts trying to educate UA implementors and content providers of the benefits of style sheets and semantic markup. In HTML 4.0, presentational elements were deprecated in favor of style sheets. Recommending the use of XSL-FO on the Web means a reversal of W3C's position on these matters; XSL-FO is not a style sheet language, it's exactly the opposite. It should be a warning signal to W3C when content providers intend to use one of their specifications as a "semantic firewall" [1]. Without a syntax to express formatting objects in, XSL-FO would not be a thret to accessibility and device-independence on the web. We therefore propose to express formatting objects in something other than XML. The only technical reason why formatting objects are expressed in XML today is that XSLT can only output XML. By extending XTL to express FOs in some abstract, non-syntaxed manner the problem can be avoided, and the valuable work that the XSL FO subgroup has been doing on formatting will be able to move forward. This way, the XSL group would fulfill its charter to "specify a style sheet language for XML and other structured markup languages". As the current proposal stand, we believe the group has gone outside its charter and that the result will be a web with less style sheets and more presentational markup. For an extended argument, see [2].
Disposition: Explanation of why no change will be made
This comment seems inapproriate at this point in the process.
It is clear that XML is the first choice for any document format syntax as the following excerpt for a document presented to the W3C AC indicates:
From: "Web Architecture from 50,000 feet" by Tim Berners-Lee, March 2000
...
Common Syntax for Structured documents: XML
...
While in principle anyone is free to use any syntax in a new language, the evident advantages from sharing the syntax are so great that new languages should where it is not overly damaging in other ways be written in XML. Apart from the efficiency of sharing tools, parsers, and understanding, this also leverages the work which has been put in to XML in the way of internationalization, and extensibility.
XSLT has already been defined as an XML to XML translator. The XML Infoset and the XML syntax are critical parts of the XSLT transformation process. In particular, the templates for the result fragments are expressed in XML syntax.
Originally, the transformation portion of XSL was proposed as only being an initial (hidden) step in an XSL formatter, But, with the encouragement of the W3C Director and various W3C members, XSLT was broken out as a separate processing step that is capable of writing out an XML result. As a consequence of this decision, the result tree of a styled XML document can be exported as an XML document.
Recognizing that this might lead to uses that might affect accessibility of documents, the following paragraph is being inserted at the end of section 1.1.1 Tree Transformation of the Introduction of the XSL document:
In some implementations of XSL/XSLT, the result of tree construction can be output as an XML document. This would allow an XML document which contains formatting objects and formatting properties to be output. This capability is neither necessary for an XSL processor nor is it encouraged. There are, however, cases where this is important, such as a server preparing input for a known client; for example, the way that a WAP [http://www.wapforum.org/faqs/index.htm] server prepares specialized input for a WAP capable hand held device. To preserve accessibility, designers of Web systems should not develop architectures that require (or use) the transmission of documents containing formatting objects and properties unless either the transmitter knows that the client can accept formatting objects and properties or the transmitted document contains a reference to the source document(s) used in the construction of the document with the formatting objects and properties.
We therefore believe that a change of syntax is neither feasible, necessary nor opportune at this time.
In contrast to the comment above, the response shows that the XSL WG is not "recommending" the use of documents that contain formatting objects on the Web. The XSL WG belives in the separation of presentational semantics from semantic markup. In addition, XSLT can, in principle, output the result tree in any language that can express trees. For example, there are implementations of XSLT which output HTML. Thus, in principle, XSLT stylesheets could be written that produce only a series of <p> elements modified by the style attribute to produce stylistic effects with no consideration for accessibility issues (and, of course, this can be also achieved by hand, with no recourse to XSLT.) The primary dependence of XSLT on XML is in the tree contruction process, not the output process."
Besides our problem with having a syntax for formatting objects, we would like to note the following:
- from our own experience we find it hard to evaluate a specification on formatting without having a conformance/test suite and several interoperable implementations. We suggest that the specification does not move forward until interoperable implementations exist.
Disposition: Explanation of why no change will be made
As desirable as a test suite is, the W3C process does not require one. In addition, the next step for XSL is Candidate Recommendation to insure that there is time to prove the implementability of the specification. Since there are multiple implementations in progress we will have an opportunity to establish interoperabity of these implementations.
- several of the formatting properties described redefines the
semantics as described by CSS2. We assume the XSL FO subgroup think
their solution is better, and that may very well be the case.
However, it will be hard for formatting engines to support two
slightly different interpretations. In other words, reuse of code
will be difficult as long as there are differences. Also, this is
not in the spirit of the charter:
"The intent is also that within XSL, the formatting properties and
values of CSS1/CSS2 can be used with their current meaning."
Disposition: Explanation of why no change will be made
The XSL group has worked very hard to use the CSS properties as they are currently defined. In some cases, we have required new values for existing CSS properties. This is a significantly simpler problem for an implementor of both specifications because it does not require any change for the existing valuesand the only new code is for the new values. This seems like the most reasonable way to grow a common property base.
- the shorthand properties have been given their own conformance level. It seems as if the specification encourages implementors not to support shorthand properties. Again, this is not in the spirit of the charter.
Disposition: Explanation of why no change will be made
The charter says, "Where the functionality of CSS and XSL overlap, the style information shall be exportable in both XSL and CSS.". Because the shorthand properties can be reduced to the underlying elementary properties and these elmentary properties are part of XSL, the charter requirements are met. They were not required at lower conformance levels because they require parsing of value strings that are not in XML syntax and whose assignment to a given value pair is determined by the value itself. The WG did not wish to require this additional level of complexity at lower levels of conformance.
- making XML attributes out of CSS properties has also been done by another W3C WG. MathML 1.0 contains a set of "CSS-compatible attributes". However, their solution differs from the XSL solution in subtle ways that damages interoperability and questions W3C's ability to coordinate.
Disposition: Explanation of why no change will be made
There are only five CSS properties used in MathML: font-size, font-weight, font-style, font-family and color. Based on conversations with the MathML WG, other than the spelling of the names of the hyphenated properties, MathML removes the hyphen, we are unaware of any difference in how the properties are used. In response to the MathML 2.0 last call, we have submitted a comment requesting the MathML provide an alternate spelling that has the hyphen for each of the hyphenated properties.
[1] http://www.mulberrytech.com/xsl/xsl-list/archive/msg02343.html [2] http://www.opera.com/people/howcome/1999/foch.html Regards, -h&kon Chief Technology Officer Opera Software H嫯n Wium Lie http://www.opera.com/people/howcome
Message-Id: <3.0.5.32.20000504142402.00857b80@mail-321> Date: Thu, 04 May 2000 14:24:02 -0700 To: xsl-editors@w3.org From: Stephen Deach <sdeach@Adobe.COM> Cc: "Sebastian Rahtz" <sebastian.rahtz@computing-services.oxford.ac.uk>, "Nikolai Grigoriev" <grig@iitp.ru> Subject: XSL FO: scaling graphics
In the last-call review meeting, we agreed to add this to the last-call issues as an apparent bug in the specification. >From: Sebastian Rahtz <sebastian.rahtz@computing-services.oxford.ac.uk> >To: xsl-list@mulberrytech.com >Subject: XSL FO: scaling graphics >Date: Wed, 03 May 2000 12:48:47 +0100 >Sender: owner-xsl-list@mulberrytech.com >Reply-To: xsl-list@mulberrytech.com > >Can someone advise me about scaling graphics in FO? Is the following right? > >a) I want the graphic a fixed size: > > <fo:external-graphic src="foo" content-width="4in"/> > >b) I want a fixed width and height, and non-uniform scale: > > <fo:external-graphic src="foo" scaling="non-uniform" > content-width="4in" content-height="4in"/> > >c) I want the graphic to occupy 80% of the width of the enclosing box: > > <fo:external-graphic src="foo" content-width="90%"/> > >d) I want the graphic scaled to 50% of its natural size > > ????????????????? > > >I don't see a combination of properties which lets me express d). Any suggestions? > >Sebastian Rahtz > > > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > >
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0044.html
From: "Sebastian Rahtz" <sebastian.rahtz@computing-services.oxford.ac.uk> Message-ID: <14609.64440.881538.970997@localhost.localdomain> Date: Thu, 4 May 2000 23:37:44 +0100 (BST) To: sdeach@Adobe.COM Cc: xsl-editors@w3.org, grig@iitp.ru Subject: Re: XSL FO: scaling graphics excellent, many thanks for picking that one up. in response to your other email, I am annotating a list of properties with notes on which ones I am having trouble implementing. i hope to complete that tonight sebastian
Disposition: Accepted (bug in spec)
d) can be done using the technique in c).
c) cannot be achieved currently. One can set the "viewport" to be 80% of the width of the enclosing "box", but one cannot specify the scaling of the graphic itself to fix the "viewport".
Additional value "scale-to-fit" will be added to "content-height", and "content-width" to achieve this.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
-----------------------------------------------------------------------------
This e-mail reflects the personal opinion of the author.
-- Unless explicitly so stated in the text, it does not represent an
official position of Adobe Systems, Inc.
-- Unless explicitly so stated in the text, it does not represent an
official opinion of the W3C XSL Working group.
-----------------------------------------------------------------------------
Stephen Deach | Sr Computer Scientist
408-536-6521 (office) | Adobe Systems Inc.
408-537-4214 (fax) | Mail Stop W15-424
sdeach@adobe.com (no ads) | 345 Park Ave
| San Jose, CA 95110-2704
| USA
----------------------------------------------------------------------------
To: xsl-editors@w3.org From: MURAKAMI Shinyu <murakami@nadita.com> Message-Id: <200005162031.FBA12513.LSJNBVBN@nadita.com> Date: Tue, 16 May 2000 20:31:37 +0900 Subject: XSO FO: Border/Padding conditionality Dear xsl-editor The XSL FO draft spec (WD-xsl-20000327) says the border-before-width, border-after-width, padding-before and padding-after properties of block-level formatting objects may have <length-conditional> compound values. I have some question and requests about it. <quote> 7.6.9 "border-before-width" ... <length-conditional> A compound value specifying the width and any conditionality of the border for the before-edge. The .length component is a <length>. The .conditionality component may be set to "discard" or "retain" to control if the border should be 0 or retained if it's associated edge is a leading-edge in a reference-area for areas generated from this formatting object that have an is-first value of "false". See [4.3 Spaces and Conditionality] for further details. The initial value of the .conditionality component is "retain". </quote>
Question 1. Why the initial value is "retain"?
I think .conditionality="discard" is more convenient.
.conditionality="discard"
+---------------+
|The quick brown|
|fox jumps over |
(page-or-column-break here)
|the lazy dog. |
+---------------+
VS.
.conditionality="retain"
+---------------+
|The quick brown|
|fox jumps over |
+---------------+
(page-or-column-break here)
+---------------+
|the lazy dog. |
+---------------+
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0054.html
Message-Id: <3.0.5.32.20000516094450.011c7970@mail-321> Date: Tue, 16 May 2000 09:44:50 -0700 To: xsl-editors@w3.org From: Stephen Deach <sdeach@Adobe.COM> Subject: Re: XSO FO: Border/Padding conditionality My opinions: ... In Question 1, Did we define the term "leading-edge", or should this be "before-edge"? ... ---Steve Deach
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".
(We do define the term "leading edge" in the area model).
Question 2. bug? <quote> 4.3.1 Space-resolution Rules ... The border or padding at the before-edge or after-edge of a block-area may be specified as conditional. If so, then it is set to zero if its associated edge is a leading or trailing edge in a reference-area. In this case, the border or padding is taken to be zero for purposes of the stacking constraint definitions. </quote> In this description, missing the is-first and is-last trait conditions.
Disposition: Explanation of XSL spec
No this statement applies regardless of the values of the is-fiirst and is-last traits.
Question 3. Inline-level border/padding conditionality
Why only block-level border/padding properties have <length-conditional>
values? I think border-start-width, border-end-width, padding-start
and padding-end also should take <length-conditional> values.
.conditionality="discard"
+-----
The quick |brown
---+ +-----
fox| jumps over
---+
the lazy dog.
VS.
.conditionality="retain"
+-----+
The quick |brown|
+---+ +-----+
|fox| jumps over
+---+
the lazy dog.
I think .conditionality="discard" is the initial value.
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0054.html
Message-Id: <3.0.5.32.20000516094450.011c7970@mail-321> Date: Tue, 16 May 2000 09:44:50 -0700 To: xsl-editors@w3.org From: Stephen Deach <sdeach@Adobe.COM> Subject: Re: XSO FO: Border/Padding conditionality My opinions: I agree with his suggestion on question 3, that both the inline-level edges (start/end) and the block-level edges (before/after) should have conditionality. For consistancy with CSS, the inline-level conditionality must be "discard". The current version of CSS does not address this on block-level elements, but I think both should be consistent. I recommend that we change the initial value on conditionality to "discard" on all edges. (Even though the graphic arts traditionalist in me says that "retain" is better practice.) ... ---Steve Deach
Disposition: Explanation of why no change will be made
The conditionality at the inline level should be the same (i.e. be consistent with) as the one at the block level.
Thanks, MURAKAMI Shinyu
Item 1: Accepted (clarification)
Item 2: Accepted (clarification)
Item 3: Accepted (bug in spec)
Item 4: Out of scope; responsibility of other WG
Item 5: Out of scope; responsibility of other WG
Item 6: Out of scope; responsibility of other WG
Item 7: Out of scope; responsibility of other WG
Item 8: Out of scope; responsibility of other WG
Item 1: Accepted (editorial)
Item 2: Accepted (editorial)
Item 3: Accepted (editorial)
Item 1: Explanation of XSL spec
Item 2: Accepted (new functionality)
Item 3: Accepted (clarification)
Item 1: Explanation of why no change will be made
Item 1: Explanation of why no change will be made
Item 1: Explanation of why no change will be made
Item 1: Explanation of XSL spec
Item 2: Explanation of why no change will be made
Item 3: Accepted (clarification)
Item 1: Explanation of XSL spec
Item 1: Explanation of why no change will be made
Item 1: Explanation of XSL spec
Item 2: Explanation of XSL spec
Item 1: Accepted (editorial)
Item 2: Explanation of why no change will be made
Item 3: Explanation of XSL spec
Item 4: Accepted (clarification)
Item 5: Explanation of why no change will be made
Item 6: Explanation of why no change will be made
Item 7: Explanation of why no change will be made
Item 8: Explanation of why no change will be made
Item 9: Explanation of why no change will be made
Item 10: Explanation of why no change will be made
Item 11: Accepted (editorial)
Item 12: Explanation of why no change will be made
Item 13: Explanation of why no change will be made
Item 14: Accepted (editorial)
Item 15: Accepted (editorial)
Item 16: Accepted (editorial)
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: Explanation of why no change will be made
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: Explanation of why no change will be made
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: Explanation of why no change will be made
Item 47: Accepted (editorial)
Item 48: Accepted (editorial)
Item 49: Accepted (editorial)
Item 50: Accepted (editorial)
Item 51: Accepted (clarification)
Item 52: Explanation of why no change will be made
Item 53: Accepted (editorial)
Item 54: Explanation of why no change will be made
Item 55: Accepted (editorial)
Item 56: Explanation of why no change will be made
Item 57: Accepted (editorial)
Item 58: Accepted (editorial)
Item 59: Accepted (editorial)
Item 60: Explanation of why no change will be made
Item 61: Accepted (editorial)
Item 62: Explanation of why no change will be made
Item 63: Accepted (editorial)
Item 64: Accepted (editorial)
Item 65: Accepted (editorial)
Item 66: Explanation of why no change will be made
Item 67: Explanation of why no change will be made
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: Explanation of why no change will be made
Item 76: Accepted (editorial)
Item 77: Accepted (editorial)
Item 78: Accepted (editorial)
Item 79: Explanation of why no change will be made
Item 80: Accepted (editorial)
Item 81: Accepted (editorial)
Item 82: Accepted (editorial)
Item 83: Accepted (editorial)
Item 84: Accepted (editorial)
Item 85: Explanation of why no change will be made
Item 86: Accepted (editorial)
Item 87: Explanation of why no change will be made
Item 88: Accepted (editorial)
Item 89: Accepted (editorial)
Item 90: Accepted (editorial)
Item 91: Accepted (editorial)
Item 92: Explanation of why no change will be made
Item 93: Accepted (editorial)
Item 94: Accepted (editorial)
Item 95: Accepted (editorial)
Item 1: Accepted (bug in spec)
Item 1: Explanation of why no change will be made
Item 1: Accepted (clarification)
Item 2: Accepted (clarification)
Item 1: Accepted (bug in spec)
Item 2: Accepted (bug in spec)
Item 3: Accepted (editorial)
Item 4: Accepted (clarification)
Item 5: Accepted (editorial)
Item 6: Accepted (editorial)
Item 7: Accepted (editorial)
Item 8: Accepted (clarification)
Item 9: Accepted (editorial)
Item 10: Accepted (editorial)
Item 11: Explanation of why no change will be made
Item 12: Accepted (editorial)
Item 13: Accepted (clarification)
Item 14: Accepted (editorial)
Item 15: Explanation of why no change will be made
Item 16: Accepted (editorial)
Item 17: Accepted (bug in spec)
Item 18: Accepted (bug in spec)
Item 19: Accepted (bug in spec)
Item 20: Accepted (editorial)
Item 21: Accepted (clarification)
Item 22: Accepted (clarification)
Item 23: Accepted (clarification)
Item 24: Accepted (clarification)
Item 25: Accepted (editorial)
Item 26: Accepted (clarification)
Item 27: Accepted (editorial)
Item 28: Accepted (clarification)
Item 29: Accepted (editorial)
Item 30: Accepted (editorial)
Item 31: Accepted (editorial)
Item 32: Accepted (clarification)
Item 33: Accepted (editorial)
Item 34: Accepted (editorial)
Item 35: Accepted (editorial)
Item 36: Accepted (editorial)
Item 37: Accepted (editorial)
Item 38: Accepted (clarification)
Item 39: Accepted (editorial)
Item 40: Accepted (editorial)
Item 41: Accepted (clarification)
Item 42: Accepted (editorial)
Item 43: Accepted (editorial)
Item 44: Accepted (bug in spec)
Item 45: Accepted (editorial)
Item 46: Accepted (editorial)
Item 47: Accepted (editorial)
Item 48: Accepted (editorial)
Item 1: Accepted (bug in spec)
Item 1: Accepted (clarification)
Item 1: Explanation of XSL spec
Item 2: Explanation of XSL spec
Item 1: Accepted (clarification)
Item 1: Explanation of why no change will be made
Item 2: Explanation of why no change will be made
Item 3: Explanation of why no change will be made
Item 4: Explanation of why no change will be made
Item 5: Explanation of why no change will be made
Item 1: Accepted (bug in spec)
Item 1: Explanation of why no change will be made
Item 2: Explanation of XSL spec
Item 3: Explanation of why no change will be made