Comments on XLink and XPointer from joint Linking/XSL task force

Comments on XLink and XPointer
Task Force of the XSL/XML Linking Working Groups
19 September 2000

A task force of the XSL and XML Linking WGs met in August to discuss the 
interactions between linking and styling.  The result of that work can be 
found in a draft Note[1]; the task force hopes to have answered at least 
some of the questions posed in issue XL7[2] (closed without action, but 
still of concern to many).  In the course of that work, we uncovered 
several new issues that we would like the whole Linking WG to 
consider.  (The Note mentions all of these in passing; this message 
attempts to summarize and motivate them in one location.)

Presenting an Ending Resource in a Larger Context

The Linking WG has occasionally discussed (without resolution) the problem 
of controlling the presentation of an ending resource such that some larger 
scope surrounding it can be displayed along with it, to provide context for 
understanding the resource.  The task force came up with two new concepts 
to describe how to achieve this control: Processing Context and 
Presentation Context.[3]  We were able to interpret the current XLink state 
of the art as "defaults" for "settings" of these two contexts, but it would 
be ideal to offer link authors real control over them.

We ask the WG to consider, in a future version of XLink, adding link 
metadata that will let link authors specify their desired values for 
Processing and Presentation Context as necessary.

Choosing a Stylesheet to Use for Presenting an Ending Resource

There is a question about what stylesheet to use to present an ending 
resource to a user.[4]  There are some reasonable defaults that a processor 
to take advantage of; for example, the embedded material may come from an 
XML document that has a suitable stylesheet PI in it.  However, in the case 
of embedding, a different default may suit.  In any case, it would be 
useful to provide a way for link authors to override this and choose their 
own stylesheet.

We ask the WG to consider, in a future version of XLink, adding link 
metadata that will let link authors specify their desired stylesheets for 
presentation of ending resources.

Behavior of Multiple onLoad/replace Links in a Document

Currently, the XLink specification says that the first occurrence (in 
document order) of such a link is the one that should be processed, and 
provides other guidelines as well.[5]  In the specific case of XSLT, source 
document order is not necessarily used for processing of that document; it 
is under the stylesheet author's control.  And in the general case, source 
document order cannot be guaranteed to be used by every styling 
technology.  In addition, an onLoad/replace starting resource may be 
transformed in such a fashion that it disappears from the displayed output.

Therefore, we suggest[6] that the specification be changed to recommend 
that the first onLoad/replace link encountered by an XLink application in 
the course of presentation be processed.  This is naturally 
application-dependent, but more importantly it is also stylesheet- (and 
stylesheet technology-) dependent, which we think puts the control in the 
right hands.

Non-Well-Balanced and Discontiguous Ending Resources

Currently, the XLink specification says that ending resources that consist 
of other than a single node should be presented as a "unified 
concatenation" of all the content in the location set.[7]  We believe that 
this description is underspecified.

There are two main cases of arbitrary location sets that need special 
consideration: "non-well-balanced" ranges and discontiguous series of 
ending resources.  Concatention seems to apply to treatment of the latter 
case; however, we suspect that something like "aggregation" would be a more 
useful concept than true concatenation.  In addition, aggregation is only 
one of a variety of possibly useful presentations (for example, providing a 
menu that allows for easy navigation to each location, presenting an entire 
document but putting the individual locations into reverse video and 
positioning the document view at the first location, and so on).[8]

Therefore, we recommend that the specification be changed to allow for such 
a variety of presentations, possibly only requiring that if some ending 
resources are presented, then all must be made accessible to the user (that 
is, none should be deliberately suppressed).

Problematic Aspects of Ranges

We have observed that arbitrary ranges introduce some problematic 
situations for styling.  In any styling technology whose data model 
granularity is coarser than the Infoset (which includes both XSLT and CSS, 
for example), XPointer ranges might identify material that is not 
"compliantly" expressible in styling terms.  This problem is most acute in 
the case of embedding, and, more generally, in any case where the 
presentation context is equal to the ending resource.  There is also the 
tricky case of string ranges that begin or end in the middle of a presented 
multiple-character glyph.[9]

The XSL-affiliated members of the task force are working with that group on 
the data model issue and are recommending some extension functions to tide 
developers over.  We have also recommended some strategies for "sloppy" 
application of link behavior in cases where this is acceptable to all 
applications and users involved.[10]

However, for the sake of all styling technologies with the same problem 
(some of which may not be able to be upgraded in the near future), we 
recommend that a subset of XPointer be created that eliminates ranges (and 
possibly string ranges), in order to offer a version of XPointer whose data 
model has a better match with these technologies.  In this way, 
applications could choose to claim compliance to this subset or require use 
of it as appropriate.  This subset could perhaps take the form of a new 
scheme, such as #xptr-basic(...).

Thank you for your consideration of these comments.

	Eve Maler
	for
	the XSL/XML Linking Task Force

			*		*		*

Except where noted, the following references are to W3C member-only 
resources.  We anticipate that the Note will be made publicly available soon.

[1] http://www.w3.org/XML/Group/2000/08/NOTE-xml-link-style.html
[2] http://www.w3.org/XML/Group/1999/07/LinkingIssueList.html#XL7
[3] 
http://www.w3.org/XML/Group/2000/08/NOTE-xml-link-style.html#sec-link-traversal-concepts
[4] 
http://www.w3.org/XML/Group/2000/08/NOTE-xml-link-style.html#sec-link-traversal-concepts
[5] http://www.w3.org/TR/xlink/#actuate-att (publicly available)
[6] http://www.w3.org/XML/Group/2000/08/NOTE-xml-link-style.html#b2ab5b5b7b9
[7] http://www.w3.org/TR/xlink/#show-att (publicly available)
[8] 
http://www.w3.org/XML/Group/2000/08/NOTE-xml-link-style.html#sec-discon-functions
[9] http://www.w3.org/XML/Group/2000/08/NOTE-xml-link-style.html#range-ligs
[10] 
http://www.w3.org/XML/Group/2000/08/NOTE-xml-link-style.html#spec-range-display
--
Eve Maler                                          +1 781 442 3190
Sun Microsystems XML Technology Center    eve.maler @ east.sun.com

Received on Tuesday, 19 September 2000 13:57:11 UTC