The interaction of XLink linking elements and styling has not previously been carefully described. This note, the result of an XML Linking/XSL joint task force, attempts to rectify that oversight by providing a clear conceptual model for linking and styling and suggestions for the practical application of that model using current W3C Recommendations (and Working Drafts, Candidate Recommendations, and Proposed Recommendations).
This document is a Note made available by the World Wide Web Consortium (W3C) for information only. Publication of this Note by W3C does not imply endorsement by W3C or the W3C Team, or any W3C Members, nor that the W3C has, is, or will be allocating any resources to the issues addressed by this Note.
It was produced by a joint task force of the XML Linking
and XSL Working Groups. We plan to update this Note according to
comments received and, if there is enough interest, consider promoting
parts of it into Recommendation-track specifications where appropriate.
Comments may be directed to the task force mailing list
A list of current W3C Recommendations and other
technical documents, including Working Drafts and Notes, can be found at
Chicago, Vancouver, Mountain View, et al.: World-Wide Web Consortium, XML Linking/XSL Joint Task Force, 2001.
Created in electronic form.
Linking and styling have significant interactions. On the one hand, style may be applied to elements because they participate in links. On the other, selecting a link may modify, replace, or create a new document which must then be styled.
This note introduces a conceptual model for describing the interactions of XLink linking elements and styling. It then shows how this model may be applied in two different ways:
Using current and anticipated technologies supported by existing W3C Recommendations (and Working Drafts, Candidate Recommendations, and Proposed Recommendations).
In an environment where the XSLT processor provides significantly more functionality for linking and contains several new features.
The full generality of the conceptual model cannot be represented with current Recommendations. Rather than attempt to restrict the model, we observe that by accepting default values for parts of the model, a useful, practical subset can be implemented today.
The task force used the following principles to develop the model described in this note:
The model must support applications of linking and styling for the purpose of presentation to a human audience.
There are countless XML linking applications that are not related to style at all (robots, indexing applications, etc.). At best, the conceptual framework described in this note may aid in developing interoperable, standard applications of this sort. At the very least, nothing in this note should inhibit the development of XML linking applications that are not related to style.
The model must not compromise accessibility.
This model must apply equally well to XSL and CSS.
The consequences of linking to or from non-XML resources is outside the scope of this note.
In considering this design, we felt the following requirements had to be met by any proposed solution:
The overall treatment of the ending resource is controlled
by the
The overall treatment of link traversal is controlled by
the
It must be possible to style both starting and ending resources.
It must be possible to process inbound, outbound, and third party arcs.
It must be possible to process starting resources regardless of "well-balancedness": whole documents, one or more whole nodes, an arbitrary range, including partial nodes, and non-contiguous selections of all of the above.
It must be possible to process ending resources regardless of "well-balancedness".
It must be possible to control the context in which ending resources are displayed. While whole documents are the standard context for web browsers, it is easy to imagine situations where it would be desirable to show a portion of the document that contains the target, or even just the target itself.
We must consider the consequences of encountering different sequences and nestings of starting resources with various combinations of behavior settings.
Processing XLink linking elements can be divided into two functions: link identification and link traversal. It is useful for our purposes to consider these functions separately.
XLink
In this example, the two green (and underlined) elements are starting resources. The blue (and italic) element is an ending resource. There is no explicit markup to identify ending resources, but an XLink-aware application can identify them because they are pointed to by URI references.
Linking relationships can be less obvious. Consider the case where an extended link is used:
With the addition of an extended link element, the courses in the course list also become starting resources. Note that this makes the first course in the course list (identified in red and bold-italic) both a starting resource and an ending resource. This example could be complicated further by placing the extended link in a physically separate resource from the documents in question.
In order for links to be styled, they must be identified. The XLink-aware application must somehow provide additional information beyond what is explicitly marked up in the document available to the styling engine. This can be described in terms of &infoset; contributions.
Conceptually, the XLink-aware application must provide additional information to the styling engine about links in a document. This can be modeled in terms of contributions to the document's &infoset;.
We use the &infoset; here as a conceptual model. We are not suggesting that applications be required to build or maintain any specific set of data structures for this purpose, merely that they be able to provide certain information to the application.
Because it is convenient to describe some aspects of link processing in terms of the XPath data model, we use mostly &elemii; in our contributions, but that does mean that implementations are required to construct their internal data models that way.
An XLink-aware processor has at its disposal some
collection of XLinks. They may come from
To augment the &infoset;, we introduce a new data structure, the Link Set, and three new properties to access it. The Link Set holds an interpretation of the XLink data model: the links, arcs, and participants that are known as well as any additional metadata about them that may be available.
We construct the Link Set using &elemii;s. Note, however, that these elements are not the children of any information items in the document's &infoset;. They are accessible only through new properties. We elected to use &elemii;s for the Link Set because:
It is a hierarchical data structure with a natural tree structure.
Style engines already have well-understood mechanisms for navigating through a tree of elements and attributes.
XLinks can have additional metadata elements inside them, and it is possible for these elements to have semantic meaning, it is therefore necessary to provide a means for XLink processors to access them.
There are three types of &elemii;s in the Link Set: &linkii;s, which represent links, &arcii;s which represent single arcs, and two &partii;s which represent the start and end of an arc.
More formally:
In the case of simple links, there will only ever be a single arc,
but extended links may include many. Note that the number of &arcii;s
is not necessarily the same as the number of
Finally,
Once constructed, the new information items must be inserted into the &infoset;. We define new properties for this purpose.
Every Element, Character, Processing Instruction, and Comment Information Item in the document is augmented with two new properties: &startpa; and &endpa;.
If an information item has more than one &arcii; associated with it, they are ordered. That is, one can refer to the first &arcii;, the second &arcii;, etc. There is no requirement for different implementations to select the same order, or even for the same implementation to select the same order over multiple runs. They need only be consistent for the logical duration of any given information set.
If more than one information item in the document is associated with an arc (for example, if the starting or ending resources are comprised of several elements or a range of characters), the &startpa; or &endpa; of each relevant information item in the &infoset; is augmented.
Once the &infoset; has been augmented with these items, linking applications can process links in a uniform way, independent of whether the elements in question are simple, extended, or even third party links.
We observe that this interface extends even beyond XLink. Processors for schemas that have linking semantics defined independent of XLink, such as HTML, can augment the &infoset; and take advantage of this linking framework without literally making every link an XLink.
An XLink can be quite complex. In the most general case, linking
semantics may be influenced by the roles of the
In order to provide fully qualified names for the linking information
items, they are placed in the linking and style namespace with
This namespace name (URI) will only be used to refer to this version of this Note: different URIs will be used for any and all new versions of the specification except that this namespace name may be reused in any update of this Note which is made for the purpose of clarification or bug fixes. These changes will be minor in that they will not (a) change the meaning or validity of existing documents written using the namespace, or (b) affect the operation of existing software written to process such documents.
A &linkii; is an &elemii;. It must conform to the following
It has the following properties:
The value of the
The
This property is null if the
The
This property is null if the
It may have any other properties as long as they are from a different namespace.
A &linkii; must contain at least one &arcii; and may contain any
number of
An &arcii; is an &elemii;. It must conform to the following XML Schema type definition:
It has the following properties:
It may have any other attributes as long as they are from a different namespace.
An &arcii; must contain a Start &partii; and an End &partii;. It may also contain any number of other elements from other namespaces.
A &partii; is an &elemii;. It must conform to the following XML Schema type definition:
It has the following properties:
It may have any other properties as long as they are from a different namespace.
A &partii; may contain any number of other elements from other namespaces.
The &elemii; for the a element in the
following document:
can be represented with one &linkii;:
For an information item that participates in several links, the situation is slightly more complex. Consider the following document:
In this document, there is one link with two arcs:
Link
The document currently being presented may be replaced by
the new resource identified as the
A new viewing context (window, frame, pane, etc.) may be
created in which to present the
The
Application-specific semantics outside the scope of this note.
In the context of styling, each of these operations
can be considered a presentation or style issue.
This is particularly the case since XLink linking elements leave
the processing of the attributes controlling presentation
(
Consequently, we will address these issues under style.
Broadly speaking, style processing can be divided into two processes: styling of resources based upon how they participate in linking and styling the results of link traversal.
In this section, we consider the process of styling link resources. This model may be applied in two different ways:
Using current and anticipated technologies supported by existing W3C Recommendations (and Working Drafts, Candidate Recommendations, and Proposed Recommendations).
In an environment where the XSLT processor provides significantly more functionality for linking and contains several new features.
Once the XLink-aware application has identified the information items that are participants in a link, styling the link becomes relatively straightforward. One can easily imagine an augmented CSS application or even a Perl script that made styling choices based upon the information obtained from the augmented &infoset;.
Styling linking resources in XSL V1.0 can be achieved with small set of extension functions. The addition of a standard extension function API, anticipated for XSLT 1.1, makes this a practical solution for the present.
There are significant drawbacks to using extension functions for
styling links, principal among them the fact that it places all of the
burden on the stylesheet author. In order to handle links between
arbitrary elements,
In the descriptions that follow, ext: must be
an
The
The
The
The following templates show how one might format a phrase
element in the source document differently depending on whether or not
it was identified as the starting resource of a link:
[This section describes hypothetical additions to XSLT and/or XSL. These additions have not been reviewed by the WG and their presence here does not indicate that they will be added to any future version of XSL.]
In order to address the problems associated with placing all of the burden of link maintenance on the stylesheet author, we need to add XLink support into XSLT in a much more significant manner.
We observe that once the XSLT processor is aware of the link relationships that exist in the source document, it could conceivably maintain those relationships across transformation. Consider a simple document with a link from node B to node D:
During transformation, for every node in the result tree, the XSLT processor knows what the context node in the source tree was when the result node was created. It follows that XSLT can, in principle, maintain the link relationships across transformation.
Some difficulties need to be addressed:
How does the stylesheet author control the selection of links?
Suppose that the source document links an element, A, in the source document with three other elements in the source document, B, C, and D. The XLink-aware processor can maintain that relationship in the result tree (linking A' with B', C', and D'), but what if the stylesheet author wishes to suppress the arc between A and C?
We suggest two new top-level XSLT elements,
What happens if a source node is never processed, or produces no nodes in the result tree?
If that source node is the sole participant at one end of an arc (or if all of the nodes in the participant resource have vanished), then that link does not occur in the result tree.
What happens if the source node is processed several times, producing disjoint nodes in the result tree?
We observe that heuristics have been described for this case in
How do you add new links to the Link Set model?
Modelling the links as &infoset; augmentation has the appealing property that it allows all of the links to be processed in the same way. But what if the stylesheet wants to add new links that should also be processed in the same way?
We propose new XSLT elements for this purpose, see
The serializer for the result tree could instantiate the link relationships that it knows about using XLink, making this a nicely self-contained system: an XLink-aware XSLT processor produces a result tree that contains XLinks.
The problem of styling these links remains.
In some cases, stylesheet authors may wish to control the selection
of links. We suggest two new top-level elements to do this:
Each of these elements has a
If the select expression in either of these elements selects nodes other than Arc and Link elements in the Link Set, they are ignored.
Presented with a complex transformation that produces several disjoint nodes (perhaps from different modes), it may be impossible for the XSLT processor to accurately identify the link targets automatically.
Although we expect heuristics to be used for most cases, we propose
a new boolean attribute to make the selection explicit:
The true(),
the element on which it occurs is the link target for all links associated
with the current context node. The use of
To better understand how this works, let's consider a concrete example. Suppose that you have a link to a chapter title and that title appears in three different places in your result tree: in the Table of Contents, at the top of the page where the chapter begins, and in the running header on the pages of that chapter.
Imagine that the heuristics would select the inline at the top of the page where the chapter begins, but you wish to make a link to the entry in the table of contents. Conceptually, the heuristic algorithm must consider all of the possible link targets and select the "best one".
By adding a
Automatic link identification is only half the battle. We still need to provide mechanisms for applying style to the transformed links.
There are two different types of styling that can be applied to links: property styling and structural styling. Property styling consists of those style changes that can be achieved by changing property values (or attributes) in the result tree. Structural styling consists of those style changes that require a restructured result tree.
Changes to fonts, foreground, and background colors are all things that can be achieved with property styling. Adding a horizontal rule above and below a resource, or putting a resource in a table, can only be achieved by structural styling.
We propose a new XSL element to provide style properties.
The select expression of
The following templates show how one might make starting resources with the "HTML" role appear blue and underlined in the result tree.
In order to support structural styling, it is essentially necessary
for a stylesheet to apply more than one template to a given source
node. At the moment, this can be accomplised with
For example,
|
|
By assigning this template a very high priority, we can assure that
it will always match first. The
Consider our earlier example of a styling a phrase that
participated in a link. While we previously had to add conditional
logic to all of our phrase-level elements, using
The following templates show how one might format elements in the source document differently depending on whether or not they are identified as the starting resource of a link:
Our original goal in writing this note was to explore how linking and style effect each other and how a processing system might reasonably deal with these issues. Several early reviewers suggested that this work could be taken further to provide a mechanism not only for providing uniform treatment of source document links, but also uniform treatment of links created by the stylesheet. In this section, we explore some of those ideas.
Consider this simple document:
Imagine for the moment that our goal is to link the persons name with some online address book. One way to do that would be to construct the link natively in the result tree vocabulary with a template like this (assuming our target is HTML):
But that has the unsatisfactory result that the link is unknown to the "link aware" processor we've been describing. That processor has already constructed a link set for the source document:
What would seem more appropriate would be to insert the resulting link into the "result document link set". The result document link set is conceptually analagous to the source document link set: it describes the linking relationships in the result document.
Up to now, the result document link set has been discussed only implicitly because it was derived solely from the source document link set.
We introduce four new XSL elements for constructing links in the
result tree link set:
An
Additional elements in other namespaces can be provided, the effect that they have on rendering the link is undefined.
An
Additional elements in other namespaces can be provided, the effect that they have on rendering the link is undefined.
The
With these elements, we can recast our earlier template as follows:
The links created by
If an explicit result tree link set is desired, when the styling process completes, it must be constructed by merging the relevant links from the source document link set (with appropriate translation into the result tree) with the links explicitly created in the result document link set.
If this is our result tree:
Pat Jones is taking CS 101
]]>Then the source document link set would contribute the following links to the result document link set:
We've introduced the "scheme" result-tree: to
express pointers into the result tree. This is just a convention for
presentation here. In a real implementation, pointers or some other
mechanism would more likely be used and if the link set were serialized,
a proper base URI would be known.
The template that constructed an explicit link would contribute:
So the resulting link set is
These elements allow the stylesheet author to construct links that become part of the unified processing model. One obvious weakness that remains is that it is not possible for these elements to link to generated text. Suppose that I have a cross reference element that is processed as follows:
There's no way to use the
One possible way to move forward would be to add a new attribute,
But this seems contrived and unsatisfactory. We invite suggestions.
After much consideration, we arrived at the conceptual model which
follows. This model exposes a significant issue in the interaction between
the current technologies for linking and styling:
We show that by selecting specific defaults within the model, we can provide expected functionality with current technology. As the technology of linking and styling matures, we'll be able to exploit more of the model with standard technologies. (Implementations will be able to exploit the entire model immediately by employing extensions to standard functionality.)
From a styling perspective, link traversal requires the styling application to retrieve the document which contains the ending resource, style it, and present it. In addition, the ending resource may get special treatment. It might, for example, be shown in reverse video or the document view might be adjusted so that the ending resource appears at the top of the viewing context.
Displaying the styled result is a complex problem because links are
between
This link expresses a relationship between the text "Chapter 5" and the element with an ID of "ch5" elsewhere in the document. It provides no specific information about the formatted result that might be presented to the reader. Online, this might become a hypertext link to some other location whereas in print it might be rendered simply as a page number in parenthesis (or not at all).
The arbitrary nature of styling transformations can make this
problem even more complex, as when the target in the source document
is rendered in multiple locations in the presented result
(See
We may also want to consider how much of the document that contains the ending resource we wish to display. HTML browsers traditionally retrieve the entire resource and display it, moving the viewing context to the point where the ending resource occurs. In the case of XML documents, we may wish to have more control. We add one additional generalization to the conceptual model for this purpose.
Rather than presenting the entire resource, we might want to
display a subresource within the document
In other words, we might wish to style a link by processing a whole document (in order to get chapter numbering correct, for example), present the third chapter in the user agent, and highlight the figure.
We describe this in terms of three distinct contexts, each identified
by a URI reference (probably including an
Informally, this is the tree that is available to the styling application. Usually this is the whole document.
In other words, the results of styling the [Presentation Context] is the content that is presented in the user agent. Often this is the whole document.
These components, plus the stylesheet to be used,
are present in the &infoset; contributions
described in
For embedded resources, we recommend that the default processing
and presentation contexts be the same as the target (see
In any case, the application
has considerable freedom in selecting the appropriate stylesheet. In some
applications it may make sense to use the same stylesheet as the source
document (particularly, perhaps, in the "embed" case); in others it may
make sense to use the XML Stylesheet PI (
Application-specific behavior can be modeled with extension metadata in the XLink linking elements. If useful subsets of this behavior become common, a future version of XLink may promote them to standard elements.
The model articulated here is the most consistent and
rational model that we could imagine. It does not,
however, produce exactly the results that might be expected in all
cases. In particular, embedding resources requires special
consideration. (Embedding resources identified by XPointer ranges
is even worse; see
Consider the following documents, doc1.xml:
and doc2.xml:
Suppose that style1.xsl styles lists with Arabic
numerals and style2.xsl styles them with Roman numerals
(and no other significant transformations are performed). What will
the results be?
If the embedded fragment is processed with style1.xsl,
the result will be something like this:
(In fact, it is even possible that the last item will be numbered "3"
if the stylesheet is only counting <item>s, but that
can be avoided in the stylesheet.)
If the embedded fragment is processed with style2.xsl,
the result will be something like this:
In neither case will the result that the author probably had in mind (namely 1, 2, 3, 4) be the result.
In fact, the desired result can be achieved, but only by constructing
the
By selecting only the content of the target list item, we allow the stylesheet for the source document to number all of the items in a logical way.
This is hardly the best possible situation, but no superior alternative seems evident.
Since both of these documents seem to use the same tag set,
it may have been closer to the author's original intention to style a
document that contained
To compound the situation further, the two most popular presentation formats for XML documents, HTML and XSL Formatting Objects, perform numbering in completely different ways.
In the HTML, list item numbering is actually done by the formatter, whereas it is done by the transformation that produces FOs in XSL. This means that the first example described above will actually work for HTML but not for XSL FOs.
Conversely, if the desired result was a mixture of numbering systems (as might be the case in a legal document, perhaps), the former result could not be achieved in HTML without considerable effort.
Consider how the stylesheets would likely produce formatting objects
for the doc1.xml:
As you can see, the list item numbers are textually part of the result tree. This is not so in the HTML case:
The list items are enumerated by the browser in the HTML case, so the numbering will be sequential.
The distinction between
At a high level,
Embedded XLinks, as we've described them, are handled during the
styling process. When an embedded XLink is processed, the
The decision about whether to use an
The actuate axis of an XLink linking element has two standard, defined values,
onRequest and onLoad. For links which have
the onRequest semantics, style processing is straightforward:
processing continues (possibly to completion) until a user event
initiates the link.
For links which have the onLoad semantic, however,
things are slightly more complicated. The styling application is
expected to process these links during the styling process
(effectively, "when the document is loaded").
There are several cases to consider:
The styling application should create a new viewing context (window, frame, pane, etc.) and display the ending resource of the link in that context.
The styling application should replace the document currently being styled with the ending resource of the link.
The
The fact that this behavior can lead to infinite loops through one or more documents is a problem outside the scope of this note.
The styling application should embed the result of styling the ending resource of the link in the current document.
The possibility of a resource that is
The styling application should create a new viewing context (window, frame, pane, etc.) and display the ending resource of the link in that context.
In other words, if A embeds B which contains an onLoad/new link to C, the result will be B embedded in A in one viewing context and C in another viewing context.
The style processor should replace the
In other words, if A embeds B which contains an onLoad/replace link to C, the result will be C embedded in A, with no trace of B.
The styling application should embed the result of styling the ending resource of the link in the current document.
In other words, if A embeds B which contains an onLoad/embed link to C, the result will be C embedded in B embedded in A.
Styling discontiguous resources presents a special set of problems. One set of problems arises because we may wish to offer behavior in the presentation engine that is independent of whether or not the resource is discontiguous. A more significant issue involves the way in which style transformations may create discontiguous resources from a single resource in the source document.
Some presentation systems implement special behaviors with respect to linking resources. For example, browsers may present links in a different color or speak them in a different tone of voice.
Often, discontiguous resources can be viewed as distinct. That is, a single resource consisting of three phrases can generally be treated like three resources, each consisting of a single phrase.
When this is not sufficient, for example, when the stylesheet author wishes to implement "mouse-over" highlighting of links and she wants discontiguous parts of the same link to be highlighted together, additional effort may be required.
The enhanced &infoset; constructed by XLink identification, provides the raw materials from which such a feature could be implemented.
The XSL Formatting Objects include properties for selecting alternate presentations based on conditions. These properties, in conjunction with a presentation system that has access to the enhanced &infoset; would allow an application to support this behavior.
Likewise for other presentation systems, access to the enhanced &infoset; provides enough information to implement the required functionality.
Transforming source documents for presentation may introduce discontinuities. For example, consider a link to a chapter title. In the document that contains the ending resource, that title is a single, unambiguous element. But when that document is styled, the chapter title may occur in several places (in the table of contents, on the chapter title page, and in a dozen cross references). Which one of these represents the ending resource?
No perfect algorithm for finding the target is readily apparent,
but reasonable heuristics have been described
To the extent that it is practical, we think applications should provide users with access to all of the possible targets.
XPointer ranges present a number of exceptional challenges to the styling process. In the simplest case, they may be used to style components that are smaller than the components exposed by the data model of a particular styling language. Consider this link:
The link is composed only of characters in the middle of a text node.
Ranges can also span normal element boundaries, producing ranges of text that are not well-formed in the XML sense:
Styling ranges (starting or ending resources expressed with XPointer ranges) in a larger context is problematic when the data model of the style language has a coarser granularity than the XML character. In particular, the XSLT 1.0 data model exposes text nodes, but not individual characters.
We propose that a reasonable processing model in this case is simply
to style the smallest available node in the data model. For example,
we expect
This will generally result in the "sloppy" application of style. For example,
will be styled as if the link were:
and
will be styled as if the link were:
If styling markup of this sort is a requirement for XSLT 2.0, as we think it is, then the data model of XSLT will have to be extended to include characters.
A few additional extension functions could be added
which would offer a laborious solution to a subset of the range
problems that can occur inside a text node through extensive use of
the
The problem of ranges in the &presctxt; is much more serious. When the &presctxt; is a range, a "sloppy" approach is unsuitable. If the link author requests that a specific range of the target document is to be presented, displaying more or or less than that range may be disastrous. Consider the case where a warning is accidentally lost or an adjacent range that has security implications is accidentally displayed.
The problem is especially troublesome when we consider embedded links. In the embedded case, we have suggested that the &presctxt; be the same as the ⌖. If an embedded link uses ranges to point to a portion of a text node, it would be entirely unacceptable to embed the entire text node.
Because the "sloppy" approach is unsuitable in this case, it follows that ranges cannot be implemented using tools that have a data model that does not address individual characters.
To tackle the difficult case introduced by ranges, we suggest that
a subset of XPointer that did not include ranges would be a useful product.
Such a subset could then be used as the data type for
&presctxt; and show="embed" ending resources.
However, we suggest the following approach of "pruning" as a possible work-around for applications which must support &presctxt;s that are defined in terms of ranges:
Identify the smallest contiguous set of whole information items which completely contains the resource in question:
Within this set, it is possible to identify three classes of information items:
Those that are wholly within the range: e.g. all the character
information items that occurs between the two emph elements.
Those that are wholly outside the range: e.g. the character information items that comprise the string "-formed".
Those that are partially within the range: e.g. the
emph &elemii;s.
Remove all information items that are wholly
In this example, only text was removed, but if additional elements had been included by the initial set of information items, they would have been removed as well.
The node set that remains after this process becomes
It is necessary for the &procctxt; to be restricted as well as the
&presctxt; because there is no practical way, in the general case,
under arbitrary transformation, for an application to trim the
Pruning prior to styling introduces the possibility that nodes which contributed to the style of the result may have been lost and therefore unexpected styling may occur.
Ranges can also be problematic if they have boundaries that occur at certain glyph and character locations.
Consider the following range:
In a visual presentation system, what is the extent of that link if the word "flying" begins with the "fl" ligature?
This problem is not limited to subtle issues of appropriate glyph selection for aesthetic purposes. In some Indic languages, for example, the actual order of the displayed glyphs may be different from the order of characters in the source. Similar problems occur in Thai, Arabic, and Hebrew, where the order and position of displayed glyphs depends on linguistic factors, not simply on the order of the characters in the source document.
It's unclear if there are any specific recommendations that can be made about this issue globally, except that avoiding character ranges, especially ranges that occur inside words, is probably best.
The distinction between normative and non-normative references is made only to emphasize the distinction between references to stable documents (W3C Recommendations, IETF RFCs, etc.) and documents that are in some sense unstable (W3C Working Drafts, etc.). W3C Notes have no normative status whatsoever.
This appendix summarizes the proposed changes to XSLT/XSL to provide better support for linking.
The true(),
the element on which it occurs is the link target for any links associated
with the current context node. The use of
We propose a new XSL element to provide style properties.
The select expression of
The
The
This note was prepared and approved for publication by the W3C XLink/XSL Joint Task Force (TF). TF approval of this note does not necessarily imply that all TF members agreed with all aspects of the note. The members of the XLink/XSL Joint TF are: