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

Glen, the XSL-FO subgroup understands the concerns that you express below. 
As you point out at the end of your message, the issues you raise have 
little practical consequence for implementors. We do recognize that we must 
be careful in re-using definitions that were designed for formatted pages 
in contexts, such as bookmarks, that are not (necessarily) formatted pages. 
However, we believe we do more service to implementors by providing the 
intended inline stacking behavior of the bookmark titles even if the 
context in which that stacked collection of inline areas is used is outside 
the XSL specification. See comments below.
At 02:05 PM 3/20/2005, Glen Mazza wrote:
> > >[Another issue:  I can't seem to find the email
> > now,
> > >but someone in the Working Group about a year or so
> > >ago mentioned that the usual descriptions of FO's
> > >generating and returning areas are not really
> > relevant
> > >for the bookmark FO's because they are off-document
> > >items.  I'm inclined to agree with that
> > idea--having
> > >an Areas returned description and Constraints
> > related
> > >to areas for the bookmark FO's are somewhat
> > confusing,
> > >because these FO's don't appear to be really part
> > of
> > >the Area Model--but rather external pointers to
> > it.]
> >
> > The point is not whether something is "off document"
> > or not,
>
>Actually it may have some relevance, because the area
>model seems to be not just about the formatting of
>individual items, but how they interact with each
>other in order to form a hierarchical arrangement of
>areas--i.e. the area tree.  Bookmarks are not part of
>the area tree--the sample tree given[1] for example
>has no "bookmark-viewport-area" descending from
>fo:root (nor is any such area defined), just
>page-viewport-areas.
>
>My concern is that having FO's that create
>off-document items--fo:bookmarks, (PDF) document
>properties (name, author, version, etc.), possibly
>fo:title--be considered as FO's creating/returning
>areas may end up corrupting the area model
>definition--see for example the page geometry
>described in the rendering model (Section 4.9 [2]).
>
>[1]
>http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#area-tree-sample
>
>[2]
>http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#rendmodel

This is a valid concern, but to date, I believe, it would be more likely 
that rooted area tree model is more likely to corrupt (well really 
influence) the expected behavior of sequences of areas such as those 
returned by bookmark title and title. The focus of the working group is on 
making the rooted area tree work (and to re-use existing work outside the 
rooted area tree where that makes sense).

> > but whether a
> > formatted displayable result is produced.
> > The
> > bookmark-title is intended to
> > be formatted into displayable form and, therefore,
> > the normal area model
> > rules are applicable to it.
>
>OK, but even with this official interpretation, a
>reasonable argument could be made that bookmarks
>should still be treated as auxiliary objects rather
>than objects creating/returning areas, given:
>
>1.)  We are not (manually) formatting bookmarks,
>rather, bookmarks are function calls to the user
>agent--with limited parameters for desired font and
>style--for the UA to display them in a UA-determined
>manner.  Too much of the physical appearance of
>bookmarks--e.g., the graphics and dotted lines between
>them, etc.--is out of control of both the stylesheet
>writer and the XSL implementation.
>
>2.)  Unlike areas in the area tree, there is no
>"future-proofing" for the formatting occurring--newer
>versions of the UA can take the same fo:bookmark
>information and display them differently (e.g., use
>different icons for the open/close graphics, etc.)
>
>3.)  Too many of the area model rules (borders,
>padding, stacking) for bookmarks would be handled by
>the UA--but it is not the responsibility of the UA to
>be conformant with the XSL recommendation, nor can the
>XSL implementation have control over this.

The points you raise are valid. They are the direct result of saying that 
the formatting of bookmarks is outside the scope of the Specification and 
is to the particular user agent. Only by writing a specification for the 
presentation of bookmarks would these issues be resolved, perhaps to the 
unhappiness of implementors that wish to use bookmark presentation to 
distinguish their product. Just because we have not written that complete 
presentation specification does not mean it is a bad idea to specify the 
inline stacking part of the presentation.


>This issue has little practical significance for
>implementors, however, so the SG's current
>interpretation is acceptable for me.
>
>Thanks,
>Glen

         Steve
=====================================
Steve Zilles
115 Lansberry Court,
Los Gatos, CA 95032-4710
steve@zilles.org