- From: Eve L. Maler <eve.maler@east.sun.com>
- Date: Tue, 19 Sep 2000 13:56:24 -0400
- To: www-xml-linking-comments@w3.org
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