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

Yes, as I has started to reply to your earlier message,
internal-destination is explicitly for linking within 
the fo result tree, and external-destination is for 
pointing outside the fo result tree, and we cannot 
mess with how {internal,external}-destination works 
without screwing them up for fo:basic-link.

The external-destination property is a URI reference, 
and its fragment identifier is supposed to be used to 
indicate a sub-resource.  This is clearly specified
in the description of external-destination and is
completely appropriate for its use on fo:basic-link;
we don't need any additional property.

I don't know how fragment identifiers would work for 
PDF bookmarks--I have not really researched or thought 
it through yet--but offhand I'd say that if the value
of the "external destination" (by whatever name) for
a bookmark should be a URI reference, then the fragment
identifier concept should work, and if the value of 
the "external destination" on a bookmark cannot be seen 
as being a URI reference, then we probably can't be using
external-destination at all for fo:bookmark.

paul

> From: [email protected] On Behalf Of Glen Mazza
> Sent: Saturday, 05 February, 2005 8:14
> To: [email protected]
> Subject: Re: FW: Action: Replies to Glen Mazza's comments on Bookmarks
> 
> 
> --- Glen Mazza <[email protected]> wrote:
> 
> > --- Steve Zilles wrote:
> > > 
> > > 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.
> > > 
> > 
> > I don't think that will work for bookmarks, because 
> > bookmarks activating another document may need both
> > properties to be set.[1]  I would recommend
> > rephrasing
> > the above for bookmarks to something similar to:
> > 
> > If both external-destination and
> > internal-destination
> > are specified, the external-destination refers to
> > the
> > file to activate, while the internal-destination
> > refers to the destination within that file to
> > activate.  If external-destination is not specified,
> > then internal-destination is a destination within
> > the
> > same document that the bookmark is in.
> > 
> > [1] PDF 1.5 Reference, Section 8.5.3 Action Types -
> > Remote Go-To Actions, Table 8.44, Keys "F"--file and
> > "D"--destination.
> > 
> 
> Two more issues came to mind here--
> 
> a.) My logic above is also relevant for fo:basic-link.
> 
> b.) My logic above of using both internal-destination
> and external-destination together nevertheless appears
> wrong for both fo:basic-link and fo:bookmark.
> 
> For external bookmarks, with the external-destination
> referencing the other document, it does not appear
> that the internal-destination property could be an
> idref pointing to the location within the external
> document, because that already-created external
> document is not being generated via the XSL process.
> Instead, it would need to be an internal identifier in
> the external document's format.  (A PDF destination
> identifier in the case of PDF.)  So the SG would
> appear to need another property for external bookmarks
> (and fo:basic-link), say, target-internal-destination
> or similar, instead of using internal-destination.  
> 
> I am unsure, however, if the SG would be willing to
> expand the spec to have a target-internal-destination
> at this time, and for that reason might recommend
> removing external-destination as an applicable
> property for fo:bookmark in XSL 1.1 as an alternative.
>  (Unless it can be considered acceptable in 1.1 to
> have external bookmarks just bring up the document
> without going to a specific page within it.)  External
> bookmarks perhaps are best for future XSL spec
> releases.
> 
> Thanks,
> Glen
> 
> 
>