- From: Paul Grosso <pgrosso@arbortext.com>
- Date: Thu, 3 Feb 2005 11:40:22 -0500
- To: <xsl-editors@w3.org>
- Message-ID: <F13E1BF26B19BA40AF3C0DE7D4DA0C0302FD31F2@ati-mail01.arbortext.local>
Forwarding to xsl-editors list.
________________________________
From: w3c-xsl-fo-sg-request@w3.org [mailto:w3c-xsl-fo-sg-request@w3.org]
On Behalf Of Steve Zilles
Sent: Wednesday, 02 February, 2005 4:15
To: w3c-xsl-fo-sg@w3.org
Subject: Action: Replies to Glen Mazza's comments on Bookmarks
31.) Section 6.11.2 fo:bookmark [1] and 6.11.3
fo:bookmark-title are
both declared to have the common accessibility properties
applicable for
them. However, the description of both common accessibility
properties
[2] states that they are applicable only for FO's that are valid
within
fo:flow and fo:static-content. (E.g., fo:root, fo:flow, and
fo:static-content do *not* have these properties applicable for
them.)
But fo:bookmark-tree and its children are outside fo:flow and
fo:static-content. So there is an inconsistency here that can
be
fixed
by either revisiting the need for fo:bookmarks to support CAP,
or by
removing the limitations stated in [2].
[1]
http://www.w3.org/TR/xsl11/#fo_bookmark
[2]
http://www.w3.org/TR/xsl11/#common-accessibility-properties
The full statement that is being referred to in the description of
the
Common Accessibility properties says:
It is used by all formatting objects that can be contained in fo:flow or
fo:static-content (all formatting objects that can be directly created
from
an XML source element).
The parenthetical part of the above statement expresses an intent; this
intent is
consistent with recording where something 'came from' in generating the
XSL-FO tree. Hence the error is not is allowing it on bookmark FOs, but
the
error is in the implication that these properties can be used (only) on
FOs
that are or descend from fo:flow or fo:static-content.
The Working Group believes that these properties can be used with all
formatting objects that can be directly created from an XML source
element.
This, however, is all formatting objects, so I am not sure why the
statement is made at all. Furthermore, this property is never
"used" by any
FO; it is only there to provide a level of traceability for a process
that
transforms the XSL-FO for another purpose, such as providing
accessibility
via another medium such as speech. Therefore, the comment is resolved
by
removing the referenced description paragraphs from
"source-document" and
"role".
33.) Section 6.11.2
fo:bookmark: The new fo:bookmark has three other
properties defined for it: external-destination [4],
internal-destination [5], and starting-state.[6] The
definitions
for
these properties need to be updated however because they carry
over from
1.0 and each hardcode the specific behavior of the then-only FO
that
used that property. (For [4] and [5], fo:basic-link, and [6]
fo:multi-case.)
It would probably be best to remove fo-specific references from
these
three property definitions, and then state something similar to
"see
the
FO for additional FO-specific behavior of this property."
(Another
option would be to add the bookmark-specific behavior with
respect to
these properties to the property definitions. Currently, we're
doing
both, for example, for starting-state, fo:multi-case's specific
behavior
with respect to this property is "hardcoded" within the
property
definition but fo:bookmark's is defined within the FO.)
[4]
http://www.w3.org/TR/xsl11/#external-destination
[5]
http://www.w3.org/TR/xsl11/#internal-destination
[6]
http://www.w3.org/TR/xsl11/#starting-state
The Working Group agreed to resolve this comment by updating the
mentioned properties as
follows:
For "external-destination" change
Specifies the destination resource (or, when a fragment
identifier
is given, sub-resource) for an fo:basic-link.
to
Specifies a destination resource (or, when a fragment
identifier
is given, sub-resource).
For "internal-destination" change
Specifies the destination flow object of an fo:basic-link.
to
Specifies a destination formatting object within the
formatting object tree.
For both of the above properties, the sentence:
One of the external-destination and internal-destination
properties should be assigned. If both are assigned, the
system may either report it as an error, or use the
internal-destination property.
should be removed and the following "constraint" should be
added to
fo:basic-link and fo: bookmark:
One of the external-destination and internal-destination
properties should be specified. If both are specified,
the system may either report it as an error, or use the
internal-destination property.
[Note the "constraint" is the same as the removed sentence with
"assigned"
replaced by "specified" to agree with our the terminology of
section 5.
Note also that the use of "should" in hte constraint means the
neither
an external-destination nor an internal-destination is required.]
For "start-state" the change is more complex because the
property builds in
some of the semantics of multi-switch. Therefore, change the following:
show
The content of the fo:multi-case is a candidate
being displayed initially.
hide
The content of the fo:multi-case is not a candidate
for being displayed initially.Specifies if the
fo:multi-case can be initially displayed.
The parent fo:multi-switch shall choose the first
fo:multi-case child where the property
"starting-state"
has the value equal to "show".
Note:
Any number of the fo:multi-case objects may assign
"starting-state" to "show". If no
fo:multi-case has
"starting-state" property value of
"show", the contents
of no fo:multi-case should be displayed.
Note:
If no multi-case is displayed, the entire fo:multi-switch
will effectively be hidden.
to
Controls how the formatting object to which it applies
is displayed. Values have the following meanings:
show
The content of the formatting object is a candidate
for being displayed initially.
hide
The content of the formatting object is not a candidate
for being displayed initially.
Note:
For details of the typical usage of this property, see
the description of <a>fo:bookmark</a> and
<a>fo:multi-switch</a>
For fo:multi-switch, the following is added at the end of the "Trait
Derivation" section.
Note:
Any number of the fo:multi-case objects may assign
"starting-state" to "show". If no
fo:multi-case has
"starting-state" property value of
"show", the contents
of no fo:multi-case should be displayed.
[The bits that were eliminated in the change are already said in the
"Trait
Derivation" section of fo:multi-switch.]
[The constraint section of fo:bookmark already says what the
"starting-state" property does for bookmarks.]
34.) Section 6.11.3 fo:bookmark-title [7]: You may wish to
consider removing the value space limitations placed on the font-style
and font-weight properties, leaving it up to the XSL implementations of
how they wish to handle unsupported or unavailable fonts-styles and/or
font-weights, as they have to do already for fonts within regular text.
Reasons:
1. The original reason for these limitations may have had to do
with PDF bookmark limitations. But the limitations of one render-target
of course should not spill over to other render-targets as well. (With
that logic, the fact that some render-targets might not support
bookmarks at all would then suggest us doing away with fo:bookmark-tree
et. al. entirely.)
2. It seems to set a precedent--limiting the range of a
property for a particular FO--that is not really necessary. XSL
implementors already need to design fallbacks for unsupported
font-weights and font-styles in regular text usage of the font.
(Fallbacks which are indeed already discussed in these property
definitions.) Creating fallbacks for fo:bookmark-title would be no more
complex to implement, probably just reusing the same logic as used for
text.
3. The restrictions are of limited utility and make this FO
less consistent with others. Disallowing an explicit declaration of
"inherit" is strange/nonstandard, given that inheritance is allowed for
these properties. Also, the font-style property definition allows for
an oblique font to be the backup for an italic font, so explicitly
prohibiting an oblique font is of questionable value. Font weights are
frequently limited to normal/bold anyway, and methods for
handling/resolving unavailable font weights are already discussed with
the font-weight property.
[7] http://www.w3.org/TR/xsl11/#fo_bookmark-title
The reason for putting the value space limitations on bookmark-title was
to encourage interoperabilty of implementations. Informal surveys showed
that implementations only supported the limited value space, so that
restricting the value space would more likely insure interoperability.
But, it is important to note that the limitation is made in a Note and
is, therefore, non normative. The Working Group feels that this is an
appropriate compromise this both indicates which values are most
meaningful to implement and still allows a conforming implementation to
implement other values. Therefore, no change is proposed to the
specification.
46.) Section
6.11.2, fo:bookmark: The content model
for the fo:bookmark is incorrect. It should be
(bookmark-title,bookmark*) and not
(bookmark-title,bookmark+).
Your suggested correction is accurate; it will be made to the document.
[Otherwise, a user of bookmarks must recurse forever.]
49.) Section 6.11.3,
fo:bookmark-title, the two
statements listed in the Constraints section appear to
be duplicated from fo:bookmark, and are not relevant
for this FO.
It is indeed likely that these constraints were duplicated from
bookmark, but they are relevant to the fo:bookmark-title and the fix is
to change "bookmark" to "bookmark-title" in the two constraints.
51.) Section 7.22.10 Property starting-state [2], The initial
value of "show" for this property should be switched to "hide" instead,
for reasons relating to the two FO's--fo:bookmark and
fo:multi-case--that this property applies to: a.) For fo:bookmark, an
initial value of "show", would mean that, upon opening the document, all
the bookmarks and subbookmarks below them should be completely expanded
by default. That is non-standard, normally, for a (say) 20-chapter
book, you would have a list of bookmarks 1,2,3,4,...,20 in unexpanded
state, for each chapter. To see bookmark sub-levels, the user would
click on a particular chapter desired. (The PDF specification [3] would
be a good example of this usual behavior.) Having a default of "show"
would require the stylesheet author to manually include
starting-state="hide" for each of the 20 top-level fo:bookmarks, in
order to get this usual behavior. b.) For fo:multi-case, its two main
rules are as follows: 1.) The parent fo:multi-switch shall choose the
first fo:multi-case child where the property "starting-state" has the
value equal to "show". But with an initial value of "show", any
fo:multi-case without an explicit specification will always have an
computed value of "show", so the explicitly specified one might end up
getting ignored. 2.) If no fo:multi-case has "starting-state" property
value of "show", the contents of no fo:multi-case should be displayed.
The only way this behavior could obtained with a initial value of "show"
would be to manually specify "hide" on every fo:multi-case, which would
be burdensome for the stylesheet author. [2]
http://www.w3.org/TR/xsl11/#starting-state [3]
http://partners.adobe.com/public/developer/pdf/index_reference.html
While the Working Group notes that the value "hide" might be
useful to users of bookmarks, the property "starting-state"
already has an initial value of "show" and this value is
the only reasonable initial value for fo:multi-case. (Unless
a multi-switch shows some case, there will often be no way
to toggle to some other case.)
The Working Group tries to avoid having properties where the
initial value depends on the context of use. This makes parsing
more difficult and creates very large problems when an initial
value is inherited.
Another important factor here is backwards compatabiltiy with
previous versions. Therefore, to preserve compatibility with
the existing usage of "starting-state" the XSL 1.1 specification
will retain the original initial value specified in XSL 1.0.
Steve
=====================================
Steve Zilles
115 Lansberry Court,
Los Gatos, CA 95032-4710
steve@zilles.org
Received on Thursday, 3 February 2005 16:40:33 UTC