W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2005

FW: Action: Replies to Glen Mazza's comments on Bookmarks

From: Paul Grosso <pgrosso@arbortext.com>
Date: Thu, 3 Feb 2005 11:40:22 -0500
Message-ID: <F13E1BF26B19BA40AF3C0DE7D4DA0C0302FD31F2@ati-mail01.arbortext.local>
To: <xsl-editors@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:58 GMT