The W3C XML Linking Working Group. The XML Linking Working Group is designing hypertext links for XML. Engineers defining the way that links are to be written in XML have made a distinction for links between objects - 'external' links, and 'internal' links to locations within XML documents, and both types will receive detailed treatment by this group. The objective of the XML Linking Working Group is to design advanced, scalable, and maintainable hyperlinking and addressing functionality for XML. The principal draft specifications include the XML Linking Language (XLink), XML Pointer Language (XPointer), and XML Base. These represent the basis on which the work of the Linking WG will proceed. The XML Path Language (XPath) is a language for addressing parts of an XML document, designed to be used by both XSLT and XPointer; it represents a joint work of the XSL Working Group and the XML Linking Working Group. The XML Linking Working Group Co-Chairs are [2000-07] Eve Maler (Sun), Daniel Veillard (W3C). Ron Daniel of Datafusion serves as the XML Linking Interest Group chair. Previously the Co-Chairs of the XML Linking WG were Bill Smith (Sun Microsystems) and Tim Bray (Textuality)." For other references, see 'XML Linking Working Group.'

Status October 1999: As of October 8, 1999, XML linking and addressing mechanisms are described in three W3C specifications: XPath, XPointer, and XLink. XLink proper provides linking mechanisms: facilities for asserting multidirectional (as well as unidirectional) link relationships between resources, for annotating links, for out-of-line links, and extended link sets. Xpath, used by XSLT and XPointer, supports specification of locations in XML documents in terms of nodes and node lists. XPointer builds upon XPath to support specification of locations for the "internal structures" of XML documents such as character strings and selections.

XLink (XML Linking Language) "specifies constructs that may be inserted into XML resources to describe links between objects. It uses XML syntax to create structures that can describe the simple unidirectional hyperlinks of today's HTML as well as more sophisticated multi-ended and typed links."

XPointer (XML Pointer Language) "specifies a language that builds upon the XML Path Language (XPath), to support addressing into the internal structures of XML documents. In particular, it provides for specific reference to elements, character strings, selections, and other parts of XML documents, whether or not they bear an explicit ID attribute, using traversals of a document's structure and choice of parts based on their properties such as element types, attribute values, character content, and relative position, containment, and order. XPointer defines the meaning of the 'selector' or 'fragment identifier' portion of URIs that locate resources of MIME media types 'text/xml' and 'application/xml'."

XPath (XML Path Language) "is a language for addressing parts of an XML document, designed to be used by both XSLT and XPointer. XPath is the result of an effort to provide a common syntax and semantics for functionality shared between XSL Transformations and XPointer. The primary purpose of XPath is to address parts of an XML document. In support of this primary purpose, it also provides basic facilities for manipulation of strings, numbers and booleans. XPath uses a compact, non-XML syntax to facilitate use of XPath within URIs and XML attribute values. XPath operates on the abstract, logical structure of an XML document, rather than its surface syntax; it models an XML document as a tree of nodes as described in [5 Data Model]. XPath gets its name from its use of a path notation as in URLs for navigating through the hierarchical structure of an XML document."

XML Base proposes syntax for providing the equivalent of HTML BASE functionality generically in XML documents by defining an XML attribute named xml:base.

Historical Note: As of March 1998, the W3C effort and corresponding specifications for XML linking and pointing/addressing mechanisms formerly subsumed under the name "Extensible Linking Language (XLL)" were provisionally renamed XLink. As of June 1998, it appeared that the label "XLL" would persist, and perhaps become the name of a new Working Group for XML linking. The XLL design work has already been subdivided into two components: XLink (proper) and XPointer. Earlier information about XLink and XPointer under the name "Extensible Linking Language (XLL)" may be found via the primary XML Page.

XLL as a broad term for XML hyperlinking (linking and addressing) has two major components: XLink and XPointer [now three: also XPath].

XLink (proper) is currently defined in the W3C Working Draft document XML Linking Language (XLink), W3C Working Draft 20-December-1999. The specification "defines the XML Linking Language (XLink), which allows elements to be inserted into XML documents in order to create and describe links between resources. It uses XML syntax to create structures that can describe the simple unidirectional hyperlinks of today's HTML as well as more sophisticated links."

XPointer, the companion specification, defines a language which is expected to be used with XLink. The current draft for XPointer is also a W3C Working Draft, XML Pointer Language (XPointer), WD-xptr-19980303. This specification defines "constructs that support addressing into the internal structures of XML documents. In particular, it provides for specific reference to elements, character strings, and other parts of XML documents, whether or not they bear an explicit ID attribute."

A related W3C document released as a 'NOTE' "explicates the design principles behind the XLink language and its related XPointer language"; see "XML Linking Language (XLink) Design Principles." The two working drafts and the design document have been edited by Eve Maler (ArborText) and Steve DeRose (Inso Corp. and Brown University).

In an overview of XLink and XPointer mechanisms, Eve Maler explained the relationship of XLink and XPointer as follows: "XLink governs how you insert links into your XML document, where the link might point to anything (e.g., a GIF file); XPointer governs the fragment identifier that can go on a URL when you're linking to an XML document, from anywhere (e.g., from an HTML file).

Multi-directional links - HTML only provides for one-way links; using the 'Go Back' button on the browser is the only way to return to the location of the original link. With a two-way link, for example, users can return to the original location via a corresponding link at the first link's destination.

Links with multiple destinations - Users may be able to choose between different destinations from a single link.

Placing content inline from a linked document - HTML only provides one-way links to entire documents or specific places in entire documents. XLL provides for placing content directly into the document being viewed without user intervention. For example, if a user is viewing a document on chemical compounds, the document may have a section on fructose that was placed in the document from an entirely different website.

Replacing content inline from a linked document - XLL also provides for replacing content inline with updated content from another document.

[April 29, 2005]First Public Working Draft for XML Linking Language (XLink) Version 1.1. The W3C XML Core Working Group has produced a First Public Working Draft for XML Linking Language (XLink) Version 1.1 and requests feedback from W3C Members and other interested parties. XLink Version 1.0 was approved as a W3C Recommendation in June 2001. The XLink Version 1.1 Working Draft defines mechanisms to allow markup constructs "to be inserted into XML documents in order to create and describe links between resources. It uses XML syntax to create structures that can describe links similar to the simple unidirectional hyperlinks of today's HTML, as well as more sophisticated links." Background information on this revision is published in a January 2005 Note Extending XLink 1.0, edited by Norman Walsh. The Note recognizes that XLink has been adopted by several markup vocabularies since its publication as a Recommendation, but "the current trend to migrate from DTD-based validation to schema-based validation poses additional challenges that could hamper its continued adoption." Four small changes in XLink Version 1.0 were identified which could "make XLink easier to use, reduce XLink's dependence on annotations provided by external grammars (XML DTDs or XML Schema, for example), and increase interoperability by reducing the risk of markup errors or misinterpretations." The proposed changes in Extending XLink 1.0 were: (1) to make simple XLinks an application-level default; (2) to reserve all attributes in the XLink namespace; (3) to allow Internationalized Resource Identifier [IRIs], not just URIs, to be used to identify XLink properties; (4) to provide Sample XML Schema and RELAX NG Grammars. The Version 1.1 specification now "implements all of the XLink 1.1 requirements documented in the W3C Note Extending XLink 1.0. XLink is not without its critics and the changes in this specification do not address all of the criticisms that have been leveled at XLink. But these changes do make XLink more useful in the places where it is already being used and make it practical in a variety of similar vocabularies."

[June 27, 2001] XML Linking Language (XLink) Version 1.0. W3C Recommendation 27-June-2001. This Rec version URL: http://www.w3.org/TR/2001/REC-xlink-20010627/. Latest version URL: http://www.w3.org/TR/xlink/. Edited by Steve DeRose (Brown University Scholarly Technology Group), Eve Maler (Sun Microsystems), and David Orchard (Jamcracker). Abstract: "This specification defines the XML Linking Language (XLink), which allows elements to be inserted into XML documents in order to create and describe links between resources. It uses XML syntax to create structures that can describe links similar to the simple unidirectional hyperlinks of today's HTML, as well as more sophisticated links." See also the mailing list archives for 'www-xml-linking-comments' and XLink (REC) errata. [cache]

[December 20, 2000] XML Linking Language (XLink) Issued as W3C Proposed Recommendation. On December 20, 2000, the W3C published Proposed Recommendation specifications for XLink and XML Base. XML Linking Language (XLink) Version 1.0 [W3C Proposed Recommendation 20-December-2000] has been edited by Steve DeRose (Brown University Scholarly Technology Group), Eve Maler (Sun Microsystems), and David Orchard. The XLink specification "defines the XML Linking Language (XLink), which allows elements to be inserted into XML documents in order to create and describe links between resources. It uses XML syntax to create structures that can describe links similar to the simple unidirectional hyperlinks of today's HTML, as well as more sophisticated links. XLink provides a framework for creating both basic unidirectional links and more complex linking structures. It allows XML documents to: (1) Assert linking relationships among more than two resources; (2) Associate metadata with a link; (3) Express links that reside in a location separate from the linked resources... Using XLink potentially involves using a large number of attributes for supplying important link information. In cases where the values of the desired XLink attributes are unchanging across individual instances in all the documents of a certain type, attribute value defaults (fixed or not) may be added to a DTD so that the attributes do not have to appear physically on element start-tags... This specification defines only attributes and attribute values in the XLink namespace. There is no restriction on using non-XLink attributes alongside XLink attributes. In addition, most XLink attributes are optional and the choice of simple or extended link is up to the markup designer or document creator, so a DTD that uses XLink features need not use or declare the entire set of XLink's attributes. Finally, while this specification identifies the minimum constraints on XLink markup, DTDs that use XLink are free to tighten these constraints. The use of XLink does not absolve a valid document from conforming to the constraints expressed in its governing DTD."

[December 20, 1999] The XML Linking Working Group has published a new Working Draft specification for theXML Linking Language (XLink). Reference: W3C Working Draft 20-December-1999, edited by Steve DeRose (Brown University), Eve Maler (Sun Microsystems), David Orchard (IBM Corp.), and Ben Trafford (Invited Expert). This release of the specification contains a number of graphical models which visually portray important aspects of the XLink link semantics. The working draft specification "defines the XML Linking Language (XLink), which allows elements to be inserted into XML documents in order to create and describe links between resources. It uses XML syntax to create structures that can describe the simple unidirectional hyperlinks of today's HTML as well as more sophisticated links." This WD version, which updates the July 1999 version, is believed by the working group "to be near completion; however, a few issues remain on which the Working Group seeks public feedback." Comments on the working draft may be send via email to the editors; such comments will be publicly archived. For XLink purposes, a link is an explicit relationship between two or more resources or portions of resources. XLink provides a framework for creating both basic unidirectional links and more complex linking structures. It allows XML documents to: (1) Assert linking relationships among more than two resources; (2) Associate metadata with a link; (3) Create link databases that reside in a location separate from the linked resources. An important application of XLink is in hypertext systems. Hyperlinks are links that are meaningful to end users, often being presented to them directly for use and activation. This specification defines hypertext-specific metadata that can be associated with a link. XLink is also applicable to links that are entirely machine-processed..."

[August 04, 1999] Tim Bray, writing as "Co-Chair, W3C Xlink Working Group," posted a note to the XML-DEV list on August 04, 1999 to this effect: "And I don't think it's out of place to report in this venue that the XLink WG has placed itself on a very short deadline to get its long-overdue job done. Watch for a rapid succession of Working Drafts converging to a Proposed Recommendation in the immediate future."

[March 25, 2003]W3C Publishes Recommendations for the XML Pointer Language (XPointer). Three specifications from the W3C XML Linking Working Group have been released as W3C Recommendations, signifying public review and approval by W3C as stable, normative documents designed to enhance the functionality and interoperability of the Web. XPointer Framework, XPointer element() Scheme, and XPointer xmlns() Scheme are "intended to address a core subset of the original XPointer requirements, and to serve as all or a foundational part of a fragment identifier syntax for the XML Media types." The XPointer Framework specification "defines the XML Pointer Language (XPointer) Framework, an extensible system for XML addressing that underlies additional XPointer scheme specifications. The framework is intended to be used as a basis for fragment identifiers for any resource whose Internet media type is one of text/xml, application/xml, text/xml-external-parsed-entity, or application/xml-external-parsed-entity. Other XML-based media types are also encouraged to use this framework in defining their own fragment identifier languages. The XPointer element() scheme is intended to be used with the XPointer Framework to allow basic addressing of XML elements. The XPointer xmlns() scheme is intended to be used with the XPointer Framework to allow correct interpretation of namespace prefixes in pointers, for instance, namespace-qualified scheme names and namespace-qualified element or attribute names appearing within scheme data." The XPointer xpointer() Scheme specification is still a W3C Working Draft.

[December 19, 2002] "XPointer xpointer() Scheme." W3C Working Draft 19-December-2002. Edited by Steven DeRose (Brown University Scholarly Technology Group; Bible Technologies Group), Eve Maler (Sun Microsystems), and Ron Daniel Jr. (Taxonomy Strategies). Latest version URL: http://www.w3.org/TR/xptr-xpointer/. Previous version: http://www.w3.org/TR/2002/WD-xptr-xpointer-20020710/. A posting from Ron Daniel (Acting Chair, W3C XML Linking Working Group) announces this release of the new W3C Working Draft: "People who are interested in a fully-featured method of pointing into XML documents may wish to check it out..." Abstract: "The XPointer xpointer() scheme is intended to be used with the XPointer Framework to provide a high level of functionality for addressing portions of XML documents. It is based on XPath, and adds the ability to address strings, points, and ranges in accordance with definitions provided in DOM 2: Range... This scheme supports addressing into the internal structures of XML documents and external parsed entities. It allows for examination of a document's hierarchical structure and choice of portions based on various properties, such as element types, attribute values, character content, and relative position. In particular, it provides for specific reference to elements, character strings, and other XML information, whether or not they bear an explicit ID attribute..." Status: "This specification is one of four into which the prior XPointer specification has been divided. This version addresses comments received on the XPointer Candidate Recommendation which were relevant to the xpointer() scheme it defines. Except for responding to the relevant Last Call comments, and incorporating non-substantive editorial improvements, this documents is substantially identical to that part of the Last Call XPointer specification which is not covered by XPointer Framework, XPointer xmlns() Scheme, and XPointer element() Scheme." See the comments archive.

[July 11, 2002]W3C Publishes Four Working Drafts for the XML Pointer Language (XPointer). The W3C XML Linking Working Group has released four Working Drafts relating to XPointer. W3C XPointer "supports addressing into the internal structures of XML documents, allowing for traversals of a document tree and choice of its internal parts based on various properties, such as element types, attribute values, character content, and relative position." The four specifications refactor schemes presented in the earlier W3C Candidate Recommendation for XML Pointer Language (XPointer) Version 1.0. The XPointer Framework is "an extensible system for XML addressing and underlies additional schemes. Other XML-based media types are also encouraged to use this framework in defining their own fragment identifier languages. Many types of XML-processing applications need to address into the internal structures of XML-encoded resources using URI references, for example, the XML Linking Language (XLink), XML Inclusions (XInclude), the Resource Description Framework (RDF), and SOAP V1.2. The element() scheme allows basic addressing of XML elements, the xmlns() scheme is for interpreting namespace prefixes in pointers, and xpointer() scheme allows full XML addressing." [Full context]

[September 12, 2001]XML Pointer Language (XPointer) Published as a W3C Candidate Recommendation. The W3C XML Linking Working Group has announced the release of XML Pointer Language (XPointer) Version 1.0 as a W3C Candidate Recommendation. The CR replaces the second last-call Working Draft version of January 08, 2001, and is open for public comment through March 4, 2002. XPointer is built on top of the XML Path Language (XPath), which is an expression language underlying the XSL Transformations (XSLT) language. XPointer's extensions to XPath allow it to: (1) be used in URI references to address into resources; (2) address points and ranges as well as whole nodes; (3) locate information by string matching. XPointer supports addressing into the internal structures of XML documents and external parsed entities. It allows for examination of a document's hierarchical structure and choice of its internal parts based on various properties, such as element types, attribute values, character content, and relative position. In particular, it provides for specific reference to elements, character strings, and other XML information, whether or not they bear an explicit ID attribute. The specification defines XPointer as the language to be used as the basis for a fragment identifier for any URI reference that locates a resource whose Internet media type is one of text/xml, application/xml, text/xml-external-parsed-entity, or application/xml-external-parsed-entity." [Full context]

[January 08, 2001] Second 'Last Call' Working Draft. Daniel Veillard posted an announcement for W3C's release of an updated (second) last call working draft specification for XML Pointer Language (XPointer) Version 1.0. Reference: W3C Last Call Working Draft 8-January-2001, edited by Steve DeRose (Brown University Scholarly Technology Group), Eve Maler (Sun Microsystems), and Ron Daniel Jr. (Interwoven). The working draft specification "defines the XML Pointer Language (XPointer), the language to be used as the basis for a fragment identifier for any URI reference that locates a resource whose Internet media type is one of text/xml, application/xml, text/xml-external-parsed-entity, or application/xml-external-parsed-entity. XPointer, which is based on the XML Path Language (XPath), supports addressing into the internal structures of XML documents. XPointer's extensions to XPath allow it to: (1) Address points and ranges as well as whole nodes; (2) Locate information by string matching; (3) Use addressing expressions in URI references as fragment identifiers, after suitable escaping. XPointer allows for examination of a hierarchical document structure and choice of its internal parts based on various properties, such as element types, attribute values, character content, and relative position. In particular, XPointer provides for specific reference to elements, character strings, and other parts of XML documents, whether or not they bear an explicit ID attribute. The structures located with XPointer can be used as link targets or for any other application-specific purpose. This specification does not constrain what uses an application may make of locations identified by XPointers. In particular, implementation of traversal to a resource is not constrained by this specification, and whether user 'traversal' is the purpose of an XPointer at all is application-dependent. A formatted-text browser traversal might scroll to and highlight the designated location; a structure-oriented graphical viewer or a document-relationship display might do traversal in quite a different way; and a search application, parser, archival system, or expert agent might use XPointers for other purposes entirely. The construction of linking elements in XML documents that associate arbitrary resources, including XML documents and portions thereof, is defined in a related specification, XLink." The Last Call period begins 8-January-2001 and ends 29-January-2001. Veillard says: "This second Last Call has been made necessary by a change required to XPointer to insure that URI References built using XPointer are context independant. This specific addition is detailed in section 5.2.1 of this XPointer Working Draft. Section 5.2.1 says, in part: "For any XPointer part that uses the xpointer scheme, the evaluation context of that part must be initialized to a set of namespace declarations consisting of a declaration of the xml prefix, bound to the URI http://www.w3.org/XML/1998/namespace, plus any namespace declarations specified by xmlns XPointer parts appearing to its left. Each xmlns part defines a namespace declaration as a prefix (NCName) and namespace URI (XPtrNsURI). In the event that two or more xmlns parts specify the same prefix, the rightmost one is used. Any xmlns parts attempting to override the xml prefix must be ignored..." Comments on the WD may be sent to the publicly archived mailing list.

[June 12, 2000] XPointer Specification as Candidate Recommendation. Daniel Veillard (W3C XML Linking Working Group Co-chair) announced the promotion of the W3C XML Pointer (XPointer) specification to 'Candidate Recommendation' status: XML Pointer Language (XPointer) Version 1.0. Reference: W3C Candidate Recommendation 7-June-2000, edited by Ron Daniel Jr. (Metacode Technologies, Inc.), Steve DeRose (Brown University Scholarly Technology Group), and Eve Maler (Sun Microsystems). Feedback from last call working draft has been analyzed, and the disposition of comments is available on-line. The XPointer specification "defines the XML Pointer Language (XPointer), the language to be used as the basis for a fragment identifier for any URI reference that locates a resource of Internet media type text/xml or application/xml. XPointer, which is based on the XML Path Language (XPath), supports addressing into the internal structures of XML documents. It allows for examination of a hierarchical document structure and choice of its internal parts based on various properties, such as element types, attribute values, character content, and relative position. . ." The XML Linking Working Group intends to "provide more information including an XPointer minimal testsuite, [which] will be published on the public page for the working group at http://www.w3.org/XML/Linking.html."

[December 06, 1999] The W3C XML Linking Working Group has published a 'Last call' working draft specification for XML Pointer Language (XPointer). References: W3C Last Call Working Draft 6-December-1999, edited by Steve DeRose (Brown University Scholarly Technology Group), Ron Daniel Jr. (DATAFUSION, Inc.), and Eve Maler (Sun Microsystems). The Last Call period begins 6-December-1999 and ends 27-December-1999, and the editorial team invites comment on the specification. Abstract: "This specification defines the XML Pointer Language (XPointer), the language to be used as a fragment identifier for any URI-reference that locates a resource of Internet media type text/xml or application/xml. XPointer, which is based on the XML Path Language (XPath), supports addressing into the internal structures of XML documents. It allows for traversals of a document tree and choice of its internal parts based on various properties, such as element types, attribute values, character content, and relative position."

[July 09, 1999] XML Pointer Language (XPointer). W3C Working Draft 9-July-1999. Edited by Steve DeRose (Inso Corp. and Brown University) and Ron Daniel Jr. (DATAFUSION, Inc.). "This document specifies a language that builds upon the XML Path Language (XPath), to support addressing into the internal structures of XML documents. In particular, it provides for specific reference to elements, character strings, selections, and other parts of XML documents, whether or not they bear an explicit ID attribute, using traversals of a document's structure and choice of parts based on their properties such as element types, attribute values, character content, and relative position, containment, and order."

[June 06, 2001]W3C Conceptual Model for XML Linking and Style. Members of the W3C XLink/XSL Joint Task Force (XML Linking and XSL Working Groups) have released a conceptual model specification for the interaction of XLink linking elements and styling. The document XML Linking and Style has been published as a W3C NOTE, and addresses the (hitherto unclarified) "interaction of XLink linking elements and styling." Background to the NOTE is provided in the document Introduction: "Linking and styling have significant interactions: on the one hand, style may be applied to elements because they participate in links; on the other hand, 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: (1) Using current and anticipated technologies supported by existing W3C Recommendations [and Working Drafts, Candidate Recommendations, and Proposed Recommendations]. (2) In an environment where the XSLT processor provides significantly more functionality for linking and contains several new features." Appendix B contains the (Non-Normative) "Summary of Proposed Changes to XSLT." [Full context] [cache version 2001-06-05]

[September 09, 2000] The W3C XML Linking Working Group has issued XML Base as a CR specification. Reference: W3C Candidate Recommendation 8-September-2000, edited by Jonathan Marsh (Microsoft). It "proposes a facility, similar to that of HTML BASE, for defining base URIs for parts of XML documents." The specification is considered stable by the XML Linking Working Group. The Working Group invites implementation feedback during this period. Comments on this document should be sent to the public mailing list www-xml-linking-comments@w3.org by December 8 2000. Description: "The XML Linking Language defines Extensible Markup Language (XML) 1.0 constructs to describe links between resources. One of the stated requirements on XLink is to support HTML linking constructs in a generic way. The HTML BASE element is one such construct which the XLink Working Group has considered. BASE allows authors to explicitly specify a document's base URI for the purpose of resolving relative URIs in links to external images, applets, form-processing programs, style sheets, and so on. This document describes a mechanism for providing base URI services to XLink, but as a modular specification so that other XML applications benefiting from additional control over relative URIs but not built upon XLink can also make use of it. The syntax consists of a single XML attribute named xml:base. The deployment of XML Base is through normative reference by new specifications, for example XLink and the XML Infoset. Applications and specifications built upon these new technologies will natively support XML Base. The behavior of xml:base attributes in applications based on specifications that do not have direct or indirect normative reference to XML Base is undefined."

[June 20, 2000] The XML Linking Working Group has released a second 'last call' working draft for the XML Base specification. Reference: W3C Working Draft 07-June-2000, edited by Jonathan Marsh (Microsoft). The Last Call period for this WD begins 7 June and ends 28-June-2000. XBase "proposes a facility, similar to that of HTML BASE, for defining base URIs for parts of XML documents." Description: "The XML Linking Language (XLink) defines XML constructs to describe links between resources. One of the stated requirements on XLink is to support HTML linking constructs in a generic way. The HTML BASE element is one such construct which the XLink Working Group has considered. BASE allows authors to explicitly specify a document's base URI for the purpose of resolving relative URIs in links to external images, applets, form-processing programs, style sheets, and so on. This document describes a mechanism for providing base URI services to XLink, but as a modular specification so that other XML applications benefiting from additional control over relative URIs but not built upon XLink can also make use of it. The syntax consists of a single XML attribute named xml:base. The attribute xml:base may be inserted in XML documents to specify a base URI other than the base URI of the document or external entity. The value of this attribute is interpreted as a URI Reference as defined in RFC 2396, after processing ... In namespace-aware XML processors, the "xml" prefix is bound to the namespace name http://www.w3.org/XML/1998/namespace as described in Namespaces in XML. Note that xml:base can be still used by non-namespace-aware processors. The deployment of XML Base is through normative references by new specifications, for example XLink and the XML Infoset. Applications and specifications built upon these technologies will natively support XML Base."

[February 21, 2000] A last call working draft has been published by the XML Linking Working Group for XML Base (XBase). Reference: W3C Working Draft 21-February-2000, edited by Jonathan Marsh (Microsoft). The last call review period ends 20-March-2000. The draft document "proposes syntax for providing the equivalent of HTML BASE functionality generically in XML documents by defining an XML attribute named xml:base. . . "

[December 20, 1999] New W3C Working Draft for XML Base (XBase). The W3C XML Linking Working Group has released an initial public Working Draft specification for XBase, invites comment on this draft specification. The WG's purpose in publishing this draft is to solicit feedback from the community both on the need for such a facility and the suitability of the mechanism. XML Base (XBase) (W3C Working Draft 20-December-1999) is edited by Jonathan Marsh (Microsoft). The specification "proposes syntax for providing the equivalent of HTML BASE functionality generically in XML documents by defining an XML attribute named xml:base." Rationale and description: "The XML Linking Language defines XML constructs to describe links between resources. One of the stated requirements on XLink is to support HTML 4.0 linking constructs in a generic way. The HTML BASE element is one such construct which the XLink Working Group has considered. BASE allows authors to explicitly specify a document's base URI for the purpose of resolving relative URIs in links to external images, applets, form-processing programs, style sheets, and so on. This document proposes that the functionality of BASE be provided to generic XML applications. Furthermore, it proposes that the resolution of relative URIs is not limited to the domain of XLink but is applicable to any XML application that makes use of relative URIs. In other words, this problem should be solved at the addressing (URI) level and not at the higher level of linking (XLink). This document introduces a syntax for a generic BASE functionality in XML documents by defining an xml:base attribute. The attribute xml:base may be inserted in XML documents to specify a base URI other than the base URI of the document or external entity, which is normally used to resolve relative URIs. The value of this attribute is interpreted as a URI as defined in RFC 2396. The base URI specified by xml:base sets the base URI information set property of the element on which this attribute occurs, and to its descendants except where further xml:base attributes are applied. The value of the xml:base attribute may itself be a relative URI, in which case it must itself be resolved against the base URI of the element it appears on. This base URI may have been obtained from an xml:base attribute on an ancestor element. This enables scoping behavior consistent with the xml:lang and xml:space attributes."

[December 21, 2001]W3C XML Query Working Group and XSL Working Group Release XPath 2.0 Working Draft. An initial working draft specification for the XML Path Language (XPath) 2.0 has been prepared jointly by members of the W3C XML Query Working Group and W3C XSL Working Group. XPath 2.0 defines "a language for addressing parts of an XML document, and has been derived from both XPath 1.0 and XQuery. The XPath 2.0 and XQuery 1.0 Working Drafts are generated from a common source. These languages are closely related, sharing much of the same expression syntax and semantics, and much of the text found in the two Working Drafts is identical. The primary purpose of XPath is to address parts of an XML document. XPath uses a compact, non-XML syntax to facilitate use of XPath within URIs and XML attribute values. XPath operates on the abstract, logical structure of an XML document, rather than its surface syntax. This logical structure is known as the data model, and is described in the W3C XQuery 1.0 and XPath 2.0 Data Model documents. XPath gets its name from its use of a path notation as in URLs for navigating through the hierarchical structure of an XML document." [Full context]

[November 16, 1999] XML Path Language (XPath) Version 1.0. W3C Recommendation 16-November-1999. Edited by James Clark and Steve DeRose. "XPath is a language for addressing parts of an XML document, designed to be used by both XSLT and XPointer." The errata.

[October 8, 1999] XML Path Language (XPath) Version 1.0 Published as a W3C Proposed Recommendation. As part of the W3C Style activity and W3C XML activity, the XML Linking Working Group and XSL Working Group have published the XPath specification as a PR: XML Path Language (XPath) Version 1.0. Reference: W3C Proposed Recommendation 8-October-1999, edited by James Clark and Steve DeRose. XPath specifies a language for addressing parts of an XML document, designed to be used by both XSLT and XPointer. "XPath is the result of an effort to provide a common syntax and semantics for functionality shared between XSL Transformations and XPointer. The primary purpose of XPath is to address parts of an XML document. In support of this primary purpose, it also provides basic facilities for manipulation of strings, numbers and booleans. XPath uses a compact, non-XML syntax to facilitate use of XPath within URIs and XML attribute values. XPath operates on the abstract, logical structure of an XML document, rather than its surface syntax. XPath gets its name from its use of a path notation as in URLs for navigating through the hierarchical structure of an XML document. In addition to its use for addressing, XPath is also designed so that it has a natural subset that can be used for matching (testing whether or not a node matches a pattern); this use of XPath is described in XSLT. XPath models an XML document as a tree of nodes. There are different types of nodes, including element nodes, attribute nodes and text nodes. XPath defines a way to compute a string-value for each type of node. Some types of nodes also have names. XPath fully supports XML Namespaces. Thus, the name of a node is modeled as a pair consisting of a local part and a possibly null namespace URI; this is called an expanded-name. The data model is described in detail in section 5, 'Data Model'." Available in both XML and HTML formats. Send comments to www-xpath-comments@w3.org until November 05, 1999; such comments are publicly archived.

XML Inclusion Proposal (XInclude) - XML Core Working Group

[March 23, 2000] XML Inclusions (XInclude) - New Working Draft Specification. The W3C XML Core Working Group has released a new working draft document XML Inclusions (XInclude), and invites comment on the specification. Reference: W3C Working Draft 22-March-2000, edited by Jonathan Marsh (Microsoft) and David Orchard (IBM). This revision updates the previous draft of November, 1999. The XInclude document "specifies a processing model and syntax for general purpose inclusion. Inclusion is accomplished by merging a number of XML Infosets into a single composite Infoset. Specification of the XML documents (infosets) to be merged and control over the merging process uses an XML-friendly syntax (elements, attributes, URI References). The general purpose inclusion mechanism is usable in well-formed but not necessarily valid XML documents." Background: "Many programming languages provide an inclusion mechanism to facilitate modularity. Markup languages also often have need of such a mechanism. This proposal introduces a generic mechanism for merging XML documents (as represented by their information sets)..." XInclude and XLink: "XInclude differs from the linking features described in the XML Linking Language, specifically links with the attribute value show="embed". Such links provide a media-type independent syntax for indicating that a resource is to be embedded graphically within the display of the document. XLink does not specify a specific processing model, but simply facilitates the detection of links and recognition of associated metadata by a higher level application. XInclude, on the other hand, specifies a media-type specific (XML into XML) transformation. It defines a specific processing model for merging information sets. XInclude processing occurs at a low level, often by a generic XInclude processor which makes the resulting information set available to higher level applications. Simple node inclusion as described in this specification differs from transclusion, which preserves contextual information such as style." XInclude and XML External Entities: There are a number of differences between XInclude and XML external entities which make them complimentary technologies. Processing of external entities (as with the rest of DTDs) occurs at parse time. XInclude operates on information sets and thus is orthogonal to parsing..." Comments on the working draft should be sent to the mailing list; such postings are publicly archived. Paul Grosso (ArborText, Co-Chair of the XML Core WG) says of the new working draft: "The XML Core WG plans to publish a Last Call Working Draft in the relatively near future, so comments about the current draft that wish to be considered for input to the Last Call draft should be submitted soon to the publicly archived comment mailing list."

[November 23, 1999] W3C XML Linking Working Group Publishes XInclude. A posting from Daniel Veillard to XML-DEV announces the publication of a W3C 'NOTE' from the XML Linking Working Group: XML Inclusion Proposal (XInclude). References: W3C Note 23-November-1999, edited by Jonathan Marsh (Microsoft) and David Orchard (IBM). The note is from the XML Linking Working Group as part of the W3C XML Activity. "The purpose of this document is to set forth a minimal set of requirements and introduce a processing model and syntax for a general purpose inclusion facility. Inclusion is accomplished by merging a number of XML Infosets into a single composite Infoset. Specification of the XML documents (infosets) to be merged and control over the merging process uses an XML-friendly syntax (elements, attributes, URI-References). The general purpose inclusion mechanism is usable in well-formed but not necessarily valid XML documents. The XML Linking Working Group has decided to publish the XInclude proposal as a W3C Note from the XML Linking Working Group. This is the result of the evolution of the show="parsed" behaviour found in early XLink Working Drafts. It was decided that this functionality would be better handled in the core XML specification. Hence, at this time, this document is for discussion purposes only." Comments should be sent to www-xml-linking-comments@w3.org.

XML Fragment Interchange. Reference: W3C Working Draft 1999-June-30 [or later], edited by Paul Grosso (Arbortext) and Daniel Veillard (W3C). Abstract: "The XML standard supports logical documents composed of possibly several entities. It may be desirable to view or edit one or more of the entities or parts of entities while having no interest, need, or ability to view or edit the entire document. The problem, then, is how to provide to a recipient of such a fragment the appropriate information about the context that fragment had in the larger document that is not available to the recipient. The XML Fragment WG is chartered with defining a way to send fragments of an XML document--regardless of whether the fragments are predetermined entities or not--without having to send all of the containing document up to the part in question. This document defines Version 1.0 of the [eventual] W3C Recommendation that addresses this issue." Status: "The XML Fragment Working Group, with this 1999 June 30 Working Draft considers its charter discharged. This is the XML Fragment WG's W3C Working Draft as revised to reflect comments received during Last Call review. This draft is technically ready to go to Proposed Recommendation, but the WG decided to hold at this stage to await some implementation experience and to allow possibly related work in other WGs to progress further before submitting this draft for PR." [cache]

XML Fragment Interchange Requirements. W3C Note 23-Nov-1998. "The XML standard supports logical documents composed of possibly several entities. It may be desirable to view or edit one or more of the entities or parts of entities while having no interest, need, or ability to view or edit the entire document. The problem, then, is how to provide to a recipient of such a fragment the appropriate information about the context that fragment had in the larger document that is not available to the recipient. The XML Fragment WG is chartered with defining a way to send fragments of an XML document--regardless of whether the fragments are predetermined entities or not -- without having to send all of the containing document up to the part in question. This document specifies the design principles and requirements for this activity."

[August 11, 2000] XML Fragment Interchange status: "On 1999 Sep 25, the XML Core working group submitted an official Request to make the Fragment Interchange specification a Proposed Recommendation. This Request goes to the W3C Team and Director. Ordinarily, a response to such a Request is forthcoming within days or a couple weeks. However, in the case of the Fragment Interchange spec, the Team appears to have decided that the interest level is too low to warrant any resources be put into processing this request, so it has remained an outstanding request for almost a year. Both W3C members and the user community at large are welcome to express their opinion on the importance (or lack thereof) of this spec. To date, there has been several opportunities to do so, but no outpouring of interest by either the developer or use community, so it appears that the W3C Team's reading of the interest level is not inaccurate. [From Paul Grosso, XML-DEV, 2000-08-11.

[October 25, 2000] W3C has published a NOTE under the title XLink Markup Name Control. Reference: W3C Note 24-October-2000, edited by [W3C XML Linking Working Group co-chairs] Eve Maler (Sun Microsystems) and Daniel Veillard (W3C). Document abstract: "This document proposes a possible XML Schema-based solution to the need to use XLink in XML-based languages such as XHTML 1.0." The note addresses the particular problem of 'namespaces' when attempting to upgrade existing document markup to be interpreted as XLink syntax. "Currently, XLink requires applications to recognize a particular set of attribute names in the XLink namespace in order to do their work... [suppose] you already have some marked-up information that provides some of the same kinds of linking information that XLink is designed to provide: in order to incorporate XLink usage directly into the existing vocabulary as a first-class construct, you would have to force the vocabulary to undergo a backwards-incompatible change from href to xlink:href. XLink's attributes must have namespace prefixes on them because of the way XML namespaces work; 'global' attributes that can be attached to any element must be prefixed because they cannot identify themselves in any other way..." The NOTE's proposed solution builds upon a suggestion from Henry Thompson of the W3C XML Schema Working Group. A future version of W3C XLink might allow applications "to take advantage of XML Schema datatypes instead, or in addition, as a way to recognize Schema-XLink data. The idea is that any attribute name could be used, as long as the attribute were 'marked' with an appropriate datatype, made available through a post-schema-validation information set or by other means. . . If Schema-XLink were to define such datatypes, it could provide a normative XML Schema module that merely contains a series of type definitions. Note, however, that as of this writing, XML Schema does not have facilities to specify additional normative constraints of the style that XLink needs; prose would still be needed to specify the combinations of attribute types that are expected to appear on particular 'XLink element types'..." [cache]

[September 29, 2000] A W3C Note on XLink and RDF bears the title Harvesting RDF Statements from XLinks. Reference: W3C Note 29-September-2000, edited by Ron Daniel Jr. (Metacode Technologies Inc.). This Note is not a formal product of the W3C XML Linking Working Group, but "is made available by the W3C XML Linking Working Group for the consideration of the XLink and RDF communities in the hopes that it may prove useful." Abstract: "Both XLink and RDF provide a way of asserting relations between resources. RDF is primarily for describing resources and their relations, while XLink is primarily for specifying and traversing hyperlinks. However, the overlap between the two is sufficient that a mapping from XLink links to statements in an RDF model can be defined. Such a mapping allows XLink elements to be harvested as a source of RDF statements. XLink links (hereafter, 'links') thus provide an alternate syntax for RDF information that may be useful in some situations. This Note specifies such a mapping, so that links can be harvested and RDF statements generated. The purpose of this harvesting is to create RDF models that, in some sense, represent the intent of the XML document. The purpose is not to represent the XLink structure in enough detail that a set of links could be round-tripped through an RDF model." [Principles:] "Simple RDF statements are comprised of a subject, a predicate, and an object. The subject and predicate are identified by URI references, and the object may be a URI reference or a literal string. To map an XLink link into an RDF statement, we need to be able to determine the URI references of the subject and predicate. We must also be able to determine the object, be it a URI reference or a literal. The general principle behind the mapping specified here is that each arc in a link gives rise to one RDF statement. The starting resource of the arc is mapped to the subject of the RDF statement. The ending resource of the arc is mapped to the object of the RDF statement. The arc role is mapped to the predicate of the RDF statement. However, a number of corner cases arise, described in [Section] 3, 'Mapping Specification'. RDF statements are typically collected together into 'models.' The details of how models are structured are implementation dependent. This Note assumes that harvested statements are added to 'the current model,' which is the model being constructed when the statement was harvested. But this Note, like RDFSchema, does not specify exactly how models must be structured."

[July 07, 2006] Don't Break the Link: Avoid Four Costly Pitfalls in Linking and Reuse. By Brandon Jockman. Innodata Isogen White Paper. June 2006. 9 pages. Published in the Innodata Isogen Resource Cooperative. Link management plays a vital role in establishing the overall quality of an XML-based system. Too often, organizations underestimate the significance of this key requirement -- causing systems to fall short in providing the full suite of link management services required by modern enterprises. The global transition of documents into XML prompts project requirements related to authoring, singlesource/ multiple-output publication, content management and workflow. Linking traditionally refers to a simple point-to-point link, such as a hyperlink from one Web page to another or a navigable link between two pages in a PDF document. The XML Linking Language (XLink) W3C specification1 provides an XML-based linking syntax for traditional links. However, the combination of its cumbersome authoring syntax and general lack of tool support prevents it from being the most commonly used linking syntax. Other common approaches to XML linking include ID/IDREF, W3C Schema's key/keyref, or custom links. They have limitations as well. Some common XML flavors, such as XHTML and DocBook define their own link elements. To support these custom linking syntaxes, some tools provide configurable link definition systems where custom link elements can be defined along with the type of link. However, these non-standard links may not be portable between tools. Unless adequate analysis and preparation takes place, simple linking can be anything but simple in a complex system. Linking can also include other types of referencing. This type of linking is often called use-by-reference or reuse. In a reuse link, the point-to-point link relationship has a modifier specifying that content from the target location should be pulled into the source location at a given point in time. The most complete XML-based reuse mechanism is defined by the XML Inclusions (XInclude) W3C specification..." [cache]

[July 09, 2003] "Transclusion with XSLT 2.0." By Bob DuCharme. From XML.com (July 09, 2003). "Transclusion is a hypertext concept that began in the work of Ted Nelson, who coined the term 'hypertext'. Roughly speaking, transclusion is the inclusion of a resource, or part of a resource, potentially from anywhere in the world, within a new one. For example, the HTML img element is a form of transclusion. Nelson envisioned dynamic compound documents consisting entirely of pointers to pieces of other documents, with the compound ones automatically reflecting updates to the transcluded pieces. As he wrote in his book Literary Machines 93.1: 'Transclusion will be a fundamental service of tomorrow's literary computers, and a property of the documents they will supply. Transclusion means that part of a document may be in several places -- in other documents beside the original -- without actually being copied there.' Of course, at some level, information from one server must be copied from the transcluded document to show up on the screen of the user viewing the transcluding document; but if the copy happens at read time, every time, a compound document will still have the dynamic nature that Nelson envisioned. Has transclusion been implemented in any widely-used web technology? Transclusion-like capabilities are specified in the XInclude Candidate Recommendation, but this spec tells us that 'Simple information item inclusion as described in this specification differs from transclusion, which preserves contextual information such as style.' Even then, no XInclude implementation that I know of allows the inclusion of portions of other documents; utilities such as XIncluder only allow for the transclusion of entire documents. The XLink actuate="onLoad"/show="embed" combination describes something similar, but to my knowledge browser support for it is nonexistent... The Simplified Stylesheet Modules feature of XSLT 2.0 lets you embed an XSLT template rule in a document; if the embedded template rule calls XSLT 1.0's document() function and passes it the name of the document to transclude, the input document passed to the XSLT processor can be a dummy document... When the XSLT processors built-in the major browsers implement XSLT 2.0 as they now implement 1.0, we'll have a lot of great new possibilities to work with, including the ability to include a remote document..."

[June 12, 2003]W3C Publishes Note Defining an XML Indirection Facility for XLink and XPointer. W3C has acknowledged receipt of a technical submission from ISOGEN International describing an XML Indirection Facility. As presented in the published W3C Note, XIndirect is "a simple mechanism for using XML to represent indirect addresses in order to augment the core functionality of XLink and XPointer without requiring either of those specifications to themselves require support for indirect addresses. The facilities defined are specifically designed to meet the requirements for systems that support the authoring and management of complex systems of documents. The authors do not expected that XIndirect would be normally be used for final-form delivery of hyperdocuments, although it may have value within the context of single server or small confederation of servers." UML data model diagrams are used to represent the principal objects in the XIndirect data model, which consists of four types: Linker, Pointer, Resource, and Indirector. The document also defines a simple "XML-based representation syntax for indirectors in XML documents. This syntax uses naming conventions already in wide use in other XML specifications; in particular, it uses href as the name of the pointer attribute. An informative Appendix A supplies a sample XIndirect test implementation. This style sheet uses XSLT, the EXSLT function mechanism, and the Saxon-defined evaluate() function to resolve indirectors and produce a 'debug' report showing both the ultimate results of each non-indirect pointer as well as the location paths represented by the indirector elements in the test document set." The document editor (Eliot Kimber) has provided an extended description of XIndirect's design and development, based upon the need for a generalized, optional-use indirection mechanism.

[May 05, 2003] "Creating Richer Hyperlinks with JSP Custom Tags." By Amit Goel [WWW]. From the O'Reilly Network ONJava.com (April 30, 2003). "The linking mechanism currently supported by HTML (<a href="destination.html">) allows us to create hyperlinks that can have only one destination. To add context-related destinations to a hyperlink, we either need to supply them as links within parentheses (e.g., 'download PDF version,' 'download Word version,' etc.), or make the reader scroll to a different part of the page (e.g. a 'Resources' section), sometimes causing the reader to lose context. If we could somehow embed these additional destinations within a hyperlink, we could greatly enhance the usefulness of our pages. These embedded links could point to additional resources, allowing us to pack more content into the same amount of screen space while keeping related information close at hand... What is required [for multi-destination links] is a simple, declarative, tag-like syntax that is intuitive and easy to write, just like the two hypothetical constructs described above. This would allow the developer to focus on generating content instead of worrying about the programming. Before I describe my solution, I must mention that efforts are already underway to enable such sophisticated linking models for the Web. XML and its accompanying linking standards, such as XLink and XPointer -- both currently in W3C Recommendation status -- promise support for richer hyperlinking. But these advanced linking standards are still not completely supported by the popular browsers (Internet Explorer currently does not support XLink). Besides, XLink is quite complex, and can be overkill for the average web site... This article presents a simple approach to achieving multi-destination hyperlinks using a combination of JavaServer Pages (JSP) custom tags and XML... Multi-destination link functionality is new to most web users. Given the resistance among users to learn new concepts, training users on a totally new navigation metaphor can be a challenge. Therefore, the solution presented builds on an existing and familiar navigation model -- the menu. In a menu system, users can make several choices under one main topic. Depending on the choice they make, they will reach different destinations. Multi-destination links give users the choice of where they want to go, as opposed to single-destination links. This reduces the amount of time and traffic caused by searching through unrelated links. Also, storing the embedded link information separately from the HTML content document enables page creators to update these links independently of the HTML document. This opens up interesting possibilities like adaptive hypertexts -- hypertexts that change according to the user's profile, for example -- enabling the page creators to provide links that are more relevant to the user... Finally, the role of the [proposed] drop-down icon is particularly important. It visually indicates that the associated hyperlink contains additional hyperlinks, thus differentiating multi-destination links from regular single-destination links. In addition, the optional onmouseover capability eliminates the need to click on the image, reducing the need for one extra mouse click by the user... Due to the growing amount of information available on the Web, there is a great need to navigate the Web more easily. Enhancements like these cost very little and can add a lot of richness to the Web..."

[January 23, 2003] "The Return of XML Hypertext." By Kendall Grant Clark. From XML.com. January 22, 2003. ['Kendall Clark reports on the creation of a new mailing list focused on the use of XML for hypertext.'] "... What is XML, and what is it best for, if you've spent long hours popping and pushing HyperCard stacks? Among the places one might go for an answer to these questions, consider the newly minted xml-hypertext mailing list. The first thing one might say about xml-hypertext is that its credentials suggest that it is a trustworthy source. A brief glance through its archive is like a glance through the Who's Who of the XML community. Not only is the roster of participants a good indication of the quality of conversation, but it also suggests that the list's motivating idea is not the product of a single person, but reflects broader community interests. In announcing the xml-hypertext list, Simon St. Laurent suggested a basic agenda for the conversation; 'appropriate subjects include,' St. Laurent said, 'technologies for linking and pointing, hypertext-oriented transformations, and interactions between XML and Web infrastructure'. Among the technologies which fit that bill, St. Laurent mentioned XLink, XPointer, HLink, SkunkLink, VELLUM (one of St. Laurent's own proposed linking technologies), XHTML, RDF and Topic Maps, SMIL. It makes sense that a mailing list about XML and hypertext will focus on linking technologies, since linking is essential to every robust hypertext proposal -- computing technology has long tempted very smart people as a way to overcome what is seen to be the static nature of old-fashioned, that is, printed books While it's still early, the xml-hypertext list may turn out to be an important new chorus of voices for XML technologists to pay attention to. Going forward, its two primary technical subjects of interest are likely to be new ways of rejuvenating linking in XML applications, including the end-user Web, and (though this is more a prediction than a promise) the issue of linkbases, that is, collections of out-of-band links or relations between resources..." See the information page for xml-hypertext -- Discussion of hypertext using XML and the mail archives.

[January 22, 2003] A posting from Bob DuCharme references a (demo) prototype implementation for "1-to-many" links using HTML: "While reading Micah's SkunkLink proposal, I was struck by the simplicity of using an A element to represent one-to-many links in HTML. I remember seeing an argument against this somewhere, but don't remember it, so I went ahead and prototyped an implementation. If you go to http://www.snee.com/xml/linking/1toMdemo.xml you should see a page where the green links are 1-to-many links. A [browser] View Source will show that the file is basic XHMTL, except that the green links are marked up as nested 'a' links. View Source will also show that an XSLT stylesheet is used, http://www.snee.com/xml/linking/1toM.xml (1toMdemo.xml explains why the stylesheet has an 'xml' extension) that just copies all elements through but converts 'a' elements with 'a' children to menus implemented with some JavaScript code that I learned about from a Netscape DevEdge article at http://developer.netscape.com/viewsource/smith_menu/smith_menu.html. Changing the XHTML content model for the 'a' element to allow nesting of them is an awfully small change to make to its DTD. (What would you with with deeper nesting levels? Turn them into submenus.) For 1-to-many linking in more generalized linking constructs outside of XHTML (e.g., XLink and any of the successors cropping up), this combination of XSLT plus the DevEdge menuing code makes prototyping of the linking surprisingly easy..." See followups in the XML-DEV thread. See also SkunkLink: A Common Ground for XML Linking Skunkworks by Micah Dubinko (23-December-2002) and the associated posting.

[December 23, 2002] "SkunkLink: A Common Ground for XML Linking Skunkworks." By Micah Dubinko. 23-December-2002. "The SLink language provides a data model and syntax for XML linking, suitable for use in XHTML 2.0 and related languages... The process at the W3C that led to this document started with XLL, one of the major directions for the work to be built upon the then-new XML standard. Other W3C specifications, which involved a very large number of contributors from within and without the W3C, include the XLink Recommendation and the HLink Working Draft... This document takes a fundamental approach of expressing only the author's intent for a link, leaving other kinds of link metadata and details of link processing as application-specific. As a result, many features from XLink and HLink are not included. The criteria for determining which features to include in this document is the features must be widely appropriate to many different kinds of XML languages... This document does not define a syntax for out-of-line markup, along the lines of HLink. It would, however, be straightforward to define a mapping from RDF, meta elements, or CSS syntax, to the SLink data model..."

[October 22, 2002] "The XPointer xpath1() Scheme." By Simon St.Laurent (O'Reilly & Associates). IETF Network Working Group, Internet-Draft. Reference: 'draft-stlaurent-xpath-frag-00.txt'. October 20, 2002, expires April 20, 2003. Also in HTML format. "This document specifies an xpath1() scheme for use in XPointer-based fragment identifiers. This scheme, like other XPointer Framework schemes, is designed primarily for use with the XML Media Types defined in RFC 3023, to identify locations within a given XML representation of a resource. The xpath1() scheme uses XPath 1.0 syntax... As the W3C's xpointer() scheme already provides a superset of the functionality provided by the xpath1() scheme, some consideration of why the xpath1() scheme is useful seems worthwhile. The xpointer() scheme, designed to support the out-of-line linking capabilities of XLink, provides support for character ranges which may arbitrarily cross node boundaries. While this is extremely useful for many hypertext applications, it is unnecessary for a wide variety of simpler projects, and XPath 1.0 is generally far more widely supported than the xpointer() scheme. While the XPointer Framework explicitly supports multiple levels of conformance, the xpointer() scheme states that 'Conforming XPointer processors claiming to support the xpointer() scheme must conform to the behavior defined in this specification and may conform to additional XPointer scheme specifications.' Conforming xpointer() processors must implement both XPath and the xpointer() scheme's own extensions, and while applications might use only the subset of xpointer() that is pure XPath, processors built for that approach are non-conformant. The XPointer set of specifications also includes shorthand pointers (based on ID values with their own complications) and support for an element() scheme that is effectively a subset of XPath, but these offer considerably less functionality than XPath. The xpath1() scheme strikes a balance between the simple implementation but limited functionality of shorthand pointers and the element() scheme, and the complex implementation but great capabilities of the xpointer() scheme. Perhaps more importantly, it strikes that balance using processing capabilities that are already widely deployed..." Simon notes: "Future drafts will include examples, but I suspect the readers of this list know what XPath 1.0 expressions look like. This Internet-Draft has no connection to the W3C XLink WG except insofar as it builds on the XPointer Framework and uses other W3C work as references." [cache]

[October 03, 2002] "TAG Rejects HLink." By Kendall Grant Clark. From XML.com (October 02, 2002). ['Controversy has been brewing over the HLink linking specification from the W3C's XHTML Working Group. This week in the XML-Deviant column Kendall Clark reports on the debate surrounding the W3C Technical Architecture Group's rejection of HLink in favor of XLink.'] "TAG, the W3C's Technical Architecture Group, announced recently that XLink 'should be used for hypertext references in user-interface oriented applications', and that 'it is the unanimous opinion of the TAG that XLink should be used for hypertext references in XHTML 2.0.' The announcement seemed to directly repudiate HLink, a new linking solution for XHTML. Steven Pemberton, chair of the HTML WG, suggested that HLink and XLink were two ways of doing the same thing: 'The idea is that you can define linking on markup languages using XLink concepts, and you could even define XLink itself using HLink. [HLink] is not a divergence from XLink, but an enrichment...' The TAG suggested, further, that, 'given that MathML and SVG already use XLink for hypertext references, that would seem to be precedent for using XLink in XHTML.' To which Pemberton responded: the 'fact that SMIL doesn't use XLink would seem to be a precedent for not using XLink in XHTML.' In response to TAG's claim that creating HLink falls outside XHTML 2.0's charter -- one 'design goal' goal of which is 'to use generic XML technologies as much as possible' -- Pemberton says that ''as much as possible' was added exactly to cover XLink, because it prevents us from doing the things we want to be able to do.' The first public XHTML 2.0 Working Draft, released in early August, explicitly refused to use XLink to provide hypertext linking. That refusal was foreshadowed as early as the XLink Final Call when members of the HTML WG suggested that XLink had failed to meet some of its requirements, particularly those most related to HTML linking semantics. The TAG's repudiation touched off a wide-ranging conversation, including both W3C-procedural and purely technical issues, in the XML developer community. The publication of TAG's finding followed very quickly on the heels of the HTML Working Group's public release of HLink..."

[August 26, 2002] "Top Ten Tips to Using XPath and XPointer." By John Simpson. From XML.com. August 21, 2002. ['Ten tips for XML developers from the author of XPath and XPointer. John Simpson, author of XML.com's monthly XML Q&A column, is the author of the new O'Reilly book on XPath and XPointer. This first feature is Simpson's handy list of ten XPath/XPointer tips which will increase your mastery of these essential tools.'] "XPath and XPointer allow XML developers and document authors to find and manipulate specific needles of content in an XML document's haystack. From mindful use of predicates, to processor efficiency, to exploring both the standards themselves and extensions to them, this article offers ten tips -- techniques and gotchas -- to bear in mind as you use XPath and XPointer in your own work... Beware of whitespace when counting nodes; Keep an open mind about predicates: nested, 'compound,' and so on; The string-value of a node is just a special case of the string-value of a node-set; Remember the difference between value1 != value2 and not(value1 = value2); Find and use a good tool for testing your XPath expressions; Explore EXSLT; Fail-safe your XPointers; Remember to keep namespaces straight, in both XPath and XPointer applications; Don't forget processor efficiency in XPath and XPointer; Keep an eye out for spec changes..." See the book: XPath and XPointer Locating Content in XML Documents, by John E. Simpson (O'Reilly, August 2002; ISBN: 0-596-00291-2); with full description and Table of Contents.

[March 21, 2002] "Linking in Context." By Samhaa R. El-Beltagy, Wendy Hall, David De Roure, and Leslie Carr (Department of Electronics and Computer Science, University of Southampton, Southampton SO17 1BJ, UK). In Journal of Digital Information Volume 2 Issue 3 (March 12, 2002). This paper was first presented at ACM Hypertext 2001 in August in Aarhus, Denmark, where it won the SIGWEB Douglas Engelbart Best Paper Award. ['This paper explores the idea of dynamically adding multi-destination links to Web pages, based on the context of the pages and users, as a way of assisting Web users in their information finding and navigation activities. The work does not make any preconceived assumptions about the information needs of its users. Instead it presents a method for generating links by adapting to the information needs of a community of users and for utilizing these in assisting users within this community based on their individual needs. The implementation of this work is carried out within a multi-agent framework where concepts from open hypermedia are extended and exploited. In this paper, the entities involved in the process of generating and using 'context links' as well as the techniques they employ to achieve their tasks, are described. The result of an experiment carried out to investigate the implications of linking in context on information finding, is also provided.'] "... One of the goals of the work presented is to address the limitation of switching between linkbases according to the context of documents. Another is to enable dynamic creation of links to populate linkbases. Manual authoring of links is an expensive and inefficient process..."

[March 15, 2002] "XLink: Who Cares?" By Bob DuCharme. From XML.com. March 13, 2002. "... I don't mean it rhetorically. I really want to know: who out there still cares about XLink? I did care, ever since I first heard about the work on 'XML Part 2: Linking,' as it was called at the announcement of XML's existence at SGML '96. (XSL, before XSLT was split away from XSL-FO, was Part 3). I got excited at the concept of linking that was more powerful than HTML's but easier to understand than HyTime's. I looked forward to the creation of out-of-line links that connected two, three, or more resources into a single link without requiring write access to those resources. I saw how the ability to define and assign link types would ease the end user's difficulty in navigating the growing amount of connected information on the Web. I thrilled to the talk of linkbases becoming a new category of information product to buy and sell, creating new information by making intelligent connections between existing information. XLink is the only XML-related W3C specification that took over four years to get from first Working Draft to Recommendation status. Now that it's been a stable, finished spec for eight months, we're still seeing very little activity. So what's out there? Who cares about XLink?... Perhaps the interest isn't dying away, but was merely shifted to RDF and Topic Maps, technologies that seem to be fulfilling much of the promise of XLink. Perhaps their success represents the triumph of the original ideas of XLink, with out-of-line links and linkbases finding success under different names. This would put a positive spin on the history of XLink, but I'm losing hope on seeing any large-scale use of the elements described in the XLink Recommendation. By describing resource traversal in terms of the ending resource displaying in a new window or the same window, and in terms of when it does so, the link semantics are framed in a way that can be implemented on multiple systems, so it has some of the portability and longer shelf life advantages of markup that is not presentation-oriented. But it's still about how the resources are presented to the user and is, therefore, not markup that you'd store in your core XML database or document collection that you use to generate other formats as needed. Your elements that reference footnotes would store the ID information necessary to find the right footnotes, and your news stories, legal briefs, and judges' decisions that reference legal statues would store the ID information necessary to find those. If you decided that the footnotes or legal statutes should appear in a new window, you'd have a stylesheet add the appropriate XLink markup to the version of the markup being sent to the browser -- if the browser knew what to do with XLink markup..."

[December 01, 2001] "Improving Web Linking Using XLink." By David Lowe (University of and Technology, Sydney) and Erik Wilde (Swiss Federal Institute of Technology, Zürich). Paper presented at Open Publish 2001 (First Open Publish Conference. July 30, 2001 - August 02, 2001. Sydney Hilton Hotel, Sydney, Australia). ['XML has heralded a substantial change in the way in which content can be managed. Prominent among these changes is the greatly enhanced model for linking functionality that is enabled by the emerging XLink and XPointer standards.'] "Although the Web has continuously grown and evolved since its introduction in 1989, the technical foundations have remained relatively unchanged. Of the basic technologies, URLs and HTTP has remained stable for some time now, and only HTML has changed more frequently. However, the introduction of XML has heralded a substantial change in the way in which content can be managed. One of the most significant of these changes is with respect to the greatly enhanced model for linking functionality that is enabled by the emerging XLink and XPointer standards. These standards have the capacity to fundamentally change the way in which we utilise the Web, especially with respect to the way in which users interact with information. In this paper, we will discuss some of the richer linking functionality that XLink and XPointer enable -- particularly with respect to aspects such as content transclusion, multiple source and destination links, generic linking, and the use of linkbases to add links into content over which the author has no control. The discussions will be illustrated with example XLink code fragments, and will emphasise the particular uses to which these linking concepts can be put..." [alt URL, cache]

[August 02, 2001] "XML for Data: XLink and Data. Using XLink to simplify the representation of data." By Kevin Williams (Chief XML architect, Equient, a division of Veridian). From IBM developerWorks. July 2001. ['This column takes a look at how to use XLink pointers when representing data to make XML documents more compact and flexible. Sample code shows examples of an invoice with and without the XLink pointers, plus an example of using XLinks with a URL-addressable database.'] "The W3C recently promoted a specification called XLink to Recommendation status. In this column, I take a look at XLink and how you can use it to simplify the representation and transmission of data. What is XLink, anyway? To quote the W3C XLink specification: '[T]he XML Linking Language (XLink) ... allows elements to be inserted into XML documents in order to create and describe links between resources.' The specification then goes on to assert that links defined using XLink are similar to HTML hyperlinks, leading many programmers to conclude that this is the only purpose for the specification. However, there is another way XLink can be used to great benefit: to show the relationships between data resources. Consider a typical order-tracking application, say for a large manufacturing company. An XML document describing an order would usually contain information about the customer who placed the order, the order status, and the individual line items on the order, with quantities and prices. Consumers of this document might want to use it in very different ways. In the accounting department, someone who requests the order data probably would be interested only in the total price that it needs to bill the customer -- details about the individual line items on the invoice (apart from the quantity and price) would be irrelevant. By contrast, when customers request their orders (for viewing online, perhaps), they might want to see more information, for example, the human-readable name for a part on a line item. Transmitting the entire document to each customer with full details doesn't necessarily make sense: It would be ideal to transmit just the bare bones of the order (for consumers who are interested only in the basics) with pointers to more detailed info. XLink provides a great way to accomplish that... This column demonstrates how you can use XLink's basic functionality to simplify your document structures and reduce your network transmission overhead. It looks only at the way to use simple links; XLink also provides extended link functionality, which you can use to relate many resources together (you might create an XLink linkbase that relates a customer to all of his or her orders, for example). As XML and the associated helper technologies continue to mature, programmers will have more flexibility when deciding how to implement information systems, allowing you to tune your solutions to best meet the needs of your clients..." Article also available in PDF format.

[July 16, 2001] "How to Use XLink with XML. XLink Works for Basic Links or For Embedding External Resources." By Brett McLaughlin (Enhydra strategist, Lutris Technologies). From IBM developerWorks. July 2001. ['XLink, an XML-related specification, lets you achieve dramatic linking effects in your XML documents. In this short tip learn how to include parts of other XML documents in your own XML through XLink. The code example demonstrates the technique.'] "Since the release of XML more than two years ago, an incredible amount of interest in all things 'X' has developed. As proof of this fact, you can check out a ton of XML-related specifications these days: XPointer, XLink, XSD (XML Schema), RDF, RSS, XHTML, to name a few. In this tip, I briefly explore XLink, a particularly useful specification which defines an XML linking mechanism for referring to other documents. For those of you who are HTML authors, at first XLink may sound a lot like the a element that you are so used to, as in <a href="http://www.nickelcreek.com">Check out Nickel Creek!</a>. But XLink offers much more than unidirectional linking. Using XLink, you can create bidirectional links. You can also define how links are processed, and, most important, you can allow linking from any XML element (instead of from the a element only). For all these reasons, XLink is worth knowing about..."

[April 24, 2001] "Sun IPR statement on XPointer." [Submitted to W3C by Eve L. Maler.] Posted to XML-DEV 2001-04-24. Excerpt: "This policy shall apply only to Sun's Essential Patent Claims (as defined below) that read on the XML Pointer Language specification ('XPointer'). This undertaking is valid only as long as XPointer either is on the Recommendation track or has been adopted as a Recommendation. Sun Microsystems, Inc. ('Sun') agrees it will grant royalty-free licenses, under reasonable terms and conditions, and on a non-discriminatory basis, under Sun's essential patent claims to make, use, sell, offer for sale, or import implementations of XPointer. One precondition of any license granted to a party shall be the party's agreement to grant royalty-free licenses to Sun and other companies to make, use, sell, offer for sale, or import implementations of XPointer under the party's essential patent claims. Sun expressly reserves all other rights it may have..." (see the remainder). [source]

[January 05, 2001] "XML Linking: State of the Art." By Eve Maler (Senior XML Standards Architect, Sun Microsystems XML Technology Center). 'January 2001' [no date given]. ['Eve Maler provides a detailed look into the workings of XML Linking and its related XPointer specification. Includes sample code listings.'] "Back in the early days -- that is, two years ago -- XML was most often compared to HTML, and in the eyes of many, XML came up short. HTML was a simple language anyone could learn; XML had complexities that could confuse developers. HTML had built-in formatting; XML needed a stylesheet to be displayed as anything other than raw code. HTML had hyperlinking functionality with the <A HREF> tag; XML didn't even give you a linking starter kit for embedding hyperlinks into XML in a standardized way. Today, we know that XML is scalable and flexible in ways that would stretch HTML to the breaking point, which has allowed XML to become the "universal solvent" for all data, not just the narrative information that HTML was originally designed to hold. However, if XML is to capture one of the most important features of the web, it still needs to offer a standardized way to do linking. The goal of the XML Linking Working Group of the World Wide Web Consortium is to provide exactly this, and we're closing in on our goal. This paper describes the features, benefits, and basic technical details of XML linking technologies... The XML Linking Working Group has created two specifications to solve the two main requirements of XML linking: (1) XLink is an XML vocabulary that allows XML resources to contain links themselves. XLink can be used to create HTML-style hyperlinks, but also has new features that make it easier to manage links over time and to create new "information products" consisting just of links. (2) XPointer is an adjunct to URIs that allows XML resources to be addressed into (for example, by links, XML or otherwise). XPointer can be used to get to any arbitrary region inside an XML file, unlike HTML...As of this writing, things are moving quickly in the XML linking world. XLink and XPointer (along with XML Base, another specification owned by the XML Linking WG) are in the W3C Candidate Recommendation phase, during which the W3C actively seeks implementation experience. After this phase, specifications typically move on to a Proposed Recommendation phase and then reach Recommendation status. Also, several W3C Notes have been published on technical matters related to XML linking, and one more is expected." [cache]

[October 13, 2000] Tutorials and Reference for XPointer and Extended-XLink. Jiri Jirat recently announced the availability of tutorial resources for the W3C XML Linking specifications. These materials are posted on the Zvon.org web site along with a collection of related tutorials covering XSLT, SOAP, XUL, CSS, Namespaces, etc. The online XPointer reference "allows easy access to definitions of locations, errors and functions, with links to relevant examples in XPointer tutorial. The XPointer tutorial explains the concepts of XPointer using more than 30 examples. It is aimed at 'ordinary' user, who will use XPointer mainly in the href attribute of XLink. A tutorial for extended-type XLink has also been added. The Zvon XLink reference has been updated with cross-references to examples for extended-type XLink." In this connection, note Daniel Veillard's reminder that the W3C specifications for XPointer and XLink are currently in Candidate Recommendation stage at W3C, and that the XML Linking Working Group is seeking implementation reports for XPointer and XLink. The CR stage "is dedicated to implementors, and the specifications are allowed to pursue their way toward the final Recommendation status only if the prerequisite of implementability have been verified." Implementation feedback for XPointer and Xlink may be sent to the publicly archived mailing list www-xml-linking-comments@w3.org. Review comments may also be sent to the XML Linking Working Group co-chairs, Eve Maler and Daniel Veillard.

[January 31, 2001] "XPath. [Chapter 9 in XML in a Nutshell.]" Excerpt from the book XML in a Nutshell. A Desktop Quick Reference. By Elliotte Rusty Harold and W. Scott Means. O'Reilly, January 2001. ISBN: 0-596-00058-8. "XPath is a non-XML language used to identify particular parts of XML documents. XPath lets you write expressions that refer to the document's first person element, the seventh child element of the third person element, the ID attribute of the first person element whose contents are the string 'Fred Jones,' all xml-stylesheet processing instructions in the document's prolog, and so forth. XPath indicates nodes by position, relative position, type, content, and several other criteria. XSLT uses XPath expressions to match and select particular elements in the input document for copying into the output document or further processing. XPointer uses XPath expressions to identify the particular point in or part of an XML document that an XLink links to. XPath expressions can also represent numbers, strings, or Booleans, so XSLT stylesheets carry out simple arithmetic for numbering and cross-referencing figures, tables, and equations. String manipulation in XPath lets XSLT perform tasks like making the title of a chapter uppercase in a headline, but mixed case in a reference in the body text..." Note publisher's blurn for the book: "XML in a Nutshell is just what serious XML developers need in order to take full advantage of XML's incredible potential: a comprehensive, easy-to-access desktop reference to the fundamental rules that all XML documents and authors must adhere to. This book details the grammar that specifies where tags may be placed, what they must look like, which element names are legal, how attributes attach to elements, and much more..."

[December 1999] "XML Linking." By Steven J. DeRose (Brown University Scholarly Technology Group, Brown University). In ACM Computing Surveys Volume 31, Issue 4 (December 1999). Association for Computing Machinery. "The Web Consortium's XML Linking working group is developing specifications to enable more advanced hypertext functionality on the Web: in particular fine-grained anchors, external annotation, and bi-directional links. This paper examines basic goals and approaches; describes HTML linking limitations XML Linking seeks to overcome; and surveys the Working Group's primary specifications: XPath, XPointer, and XLink. As of this writing, the last two, while well advanced, are not final recommendations, and so are subject to change. Consult the W3C Web site for the latest versions..." Also available in PDF format. [cache HTML, PDF]

[February 04, 1999] "XLink: The XML Linking Language." By Sean McGrath. In Dr. Dobb's Journal Volume 23 Number 12 (December 1998). [Internet Programming.] ISSN: 1044-789X. "The XML Linking Language (XLink) is a draft proposal from the World Wide Web consortium that addresses the shortcomings of HTML's simple hypertext model and allows the rich structure of XML documents to be fully utilized in hypertext creation and management."

"The Implications of XML for Open Hypermedia." By Leslie Carr & Wendy Hall. June 1998. Proceedings of 4th Workshop on Open Hypermedia Systems, Technical Report CS-98-01, Department of Computer Science, Aalborg University Esbjerg, Denmark. Abstract : "The authors have implemented one of a number of link services for use with the WWW, providing some open hypermedia facilities using native WWW technologies. Using this software in various projects with various information providers (some of whom have taken it up enthusiastically, others of whom remain sceptical) has raised questions about the link service. However, recent additions to the WWW, in the shape of XML and XLink, raise issues about the scope of the link services and the philosophy of OH systems in general."

[September 08, 2000] "XLink and Open Hypermedia Systems: A Preliminary Investigation." By Brent Halsey and Kenneth M. Anderson (Department of Computer Science, University of Colorado, Boulder, Boulder, CO 80309-0430, USA; Tel: 1-303-492-6003; E-mail: {halseyb, kena}@cs.colorado.edu). Pages 212-213 in Proceedings of the eleventh ACM on Hypertext and Hypermedia. May 30 - June 3, 2000, San Antonio, TX USA. "XLink is an emerging Internet standard designed to support the linking of XML documents. We present preliminary work on using XLink as an export format for the links of an open hypermedia system. Our work provides insights into XLink's suitability as a vehicle for extending the benefits of open hypermedia to the rapidly evolving world of XML. This paper presents preliminary work on using XLink as an export format for open hypermedia links. . . [Conclusions:] Our preliminary work shows that XLink can be used to capture the link structures of an existing open hypermedia system, and demonstrates that extending open hypermedia systems to export XLink information is straightforward. We believe this work also demonstrates the potential of using open hypermedia systems as authoring environments of future XML-based hyperwebs delivered over the WWW as additional XML-aware applications become available. In particular, we believe the problems described by [Hall] when using open hypermedia systems to author HTML-based hyperwebs can be avoided or mitigated."

[March 16, 1999] "Prototyping an Updating Transclusion Tool based on XLink." By Richard Tobin (University of Edinburgh), presented at XTech '99. "We have implemented prototype support for transclusion of changing material via XLink. Our tool, which makes use of the XML and XSL support in Internet Explorer Beta 2, will style and display XML documents which contain XLinks with actuate='auto' and show='embed' as if the linked-to material was actually contained within the linking element. Furthermore, we have written an update server, so that if any of the URLs contained in the XLinks so processed change, the page will be redisplayed. This update facility is restricted to URLs which are being served from an HTTP server which is also running our update server, but does NOT require polling from the client. Aside from providing a modest level of support for exploring the benefits of XLink, standoff markup and just-in-time document composition, we think the major contribution of this effort is in illustrating a relatively novel distribution of effort for handling irregularly changing information over the Web."

[August 31, 1999] "XPath: XML Path Language." By Norm Walsh. In ArborText Think Tank (August 09, 1999). "Welcome to the first regular issue of Standard Deviations from Norm. In this column, we will explore existing and emerging XML standards, learn how they work, and examine ways that you can use them in your next project. Deviating, if you'll pardon the pun, from my own plan of action, this column is not going to be as 'hands-on' as I anticipated. Instead, I'm going to introduce a relatively new but important building block for future specifications -- XPath. In future issues, we'll get to roll up our sleeves and try XPath out in the trenches. In this issue, we'll discuss the July 9, 1999 Working Draft of XPath, the XML Path Language. XPath emerged from the XSL and XPointer Working Groups. It provides a common foundation for solving a fundamental problem: How do you locate elements, attributes, and other XML document nodes in a concise, interoperable way?"

[October 13, 2000] "Data Modeling with Markup Languages (DM²L)." By by François Bry and Norbert Eisinger. Institut für Informatik der Ludwig-Maximilians-Universität München. 23 March 2000, revised 3 July 2000. "Modern markup languages, such as SGML (Standard Generalized Markup Language) and XML (eXtensible Markup Language), which were initially conceived for modeling texts, are now receiving an increasing attention as formalisms for data and knowledge modeling. XML is currently establishing itself as a successor of HTML (HyperText Markup Language) for a better modeling of texts as well as of other kinds of data. There are several reasons for this evolution..." Note the related project which deals with XLink/XPointer: "A Toolkit for Advanced XML Browsing Functionalities." [cache]

[September 22, 2000] Zvon Xlink Reference. Miloslav Nic announced 2000-09-22: "Jiri Jirat has published XLink reference and XLink examples at http://www.zvon.org/xxl/xlink/Output/xlink_refs.html and http://www.zvon.org/xxl/xlink/OutputExamples/xlinksimple_intro.html. The examples are functional If you have browser which supports Xlink (Mozilla M17 recommended), you can test real behaviour. If you do not have Xlink capable browser, you can go through tutorial where the behaviour is simulated (using JavaScript)." Main features (1) Names of elements and attributes of Xlink are clickable; (2) Click on 'Go to standard' leads to the relevant part of the W3C XLink specification; (3) Where applicable, links to relevant examples are given."

[September 22, 2000] "Out-of-Line XML Linking with X2X: Satisfying the need for better access to information." By Jason Markos (Director of Research and Development, empolis UK). Technical [white] paper. "In the past, [linking] has been enabled through either HREFs or ID/IDREFs. While these two approaches are syntactically different, they are very similar in how they work. They are both based on the conventional idea of a link being about a source file and a target file and embedding the syntax within the source file to get to the target. This approach has a number of limitations. Firstly, neither of them are bi-directional links. However, the biggest failing is that the link has no way of expressing any semantic value as to why the relationship was established. For example, HREFs rely on the text that is highlighted to explain why the link was inserted. ID/IDREFs rely on the element or it's content in a similar way. This model works if the authors understand the semantic meaning of the links that should point to or from the file that they were authoring. [Hence:] Out-of-line Linking and XLink. The fundamental principle behind 'out-of-line' linking is that the link information is stored independently of the resources that are being linked together. This concept has been around for a considerable time, but it wasn't until HyTime was produced that the idea was popularised. While XLink is a more recent standard, it is trying to solve the same problems that HyTime tries to address with regards to linking issues. Out-of-line linking has much richer functionality than the more conventional types of linking discussed earlier. This richer functionality can allow us to address some of the linking issues such as multi-directional navigation, management, validation and link semantics. There is a lot more information to be captured in an out-of-link. A link can have a title and other attributes which allows applications to distinguish different links. Each link can be viewed as a typed relationship between a number of resources. Each one of these resources can be a document, a part of a document or a data fragment. These points are represented using anchors. An anchor is a handle to a document or a position within a document. Each anchor can have a role defining the part that the anchor plays within the link. . . In summary, [the XLink tool] X2X enables you to: (1) Link between resources without the need to change them. (2) Build new documents dynamically from a template link document. (3) Have true bi-directional links between resources. (4) Group sets of related resources in strongly typed relationships. (5) Link between structured and unstructured information. (6) Manage large repositories of link information in a centralised efficient manner. (7) Link resources that are stored in a variety of different data repositories. (8) Create links using any application that creates XML XLink documents." Note: X2X from empolis UK is advertised as "the first commercial XLink engine that enables organisations to create links that are more valuable than the information they link..."

[September 22, 2000] "Out-of-Line Linking with X2X: Satisfying the need for better access to information." By Jason Markos. In Interchange [ISSN: 1463-662X] Volume 6, Number 1 (March 2000), pages 12-15. "Approximately eighty percent of all Web page accesses are from links from four key sites; search engine sites such as Alta Vista. Apart from the fact that it is very interesting that these four sites have such a monopoly, they are all dependent on links. Linking provides the potential to define relationships between information sets that can be tailored, maintained, and given extended functionality based on individual user requirements. This is not about replacing search engine technology, but further enabling it. The fundamental principle behind out-of-line linking is that the link information is stored independently of the resources that are being linked together. Once we have our link information expressed in a rich standards-based format (XLink), an important remaining issue is how to combine that link information with the resources for delivery to end users. This is often referred to as link resolving or resolution. X2X, a product from STEP UK, has been designed to provide an engine for the resolution of out-of-line links based on XLink." [See the previous entry.]

[September 22, 2000] "What is XLink?" By Fabio Arciniegas A. From XML.com (September 20, 2000). ['XLink is an XML specification for describing links between resources in XML. Our introduction shows you how to get to grips with using XLinks in your own documents.'] "The very nature of the success of the Web lies in its capability for linking resources. However, the unidirectional, simple linking structures of the Web today are not enough for the growing needs of an XML world. The official W3C solution for linking in XML is called XLink (XML Linking Language). This article explains its structure and use according to the most recent Candidate Recommendation. . . [Conclusion:] XLink is a powerful and compact specification for the use of links in XML documents. Even though XLink has not been implemented in any of the major commercial browsers yet, its impact will be crucial for the XML applications of the near future. Its extensible and easy-to-learn design should prove an advantage as the new generation of XML applications develop." Part 2 of the article is "XLink Reference."

[October 06, 2000] "XML Linking Technologies." By Eric van der Vlist. From XML.com (October 04, 2000). ['XML's flexibility provides many ways of approaching the problem of creating links between nodes. Using practical examples, this article surveys linking in XML from containment through to RDF and XLink.'] "Defining relationships between nodes of a tree is always an involved topic. During the 1990s we saw the success of relational databases, tabular data being an extreme solution to defining these relationships. In bringing hierarchical structures back to center stage, XML has revived the linking problem and presents multiple ways to solve it. In this article, we explore some of the ways to express links. We'll focus on linking nodes in a single document. Using the example of book cataloging, for each technology we will show how the example can be represented, explain how this representation can be expanded using XSLT into the most simple model, see how the document could be validated using XML Schemas, and weigh the benefits of each approach against its complexity. We take XSLT transformation as the typical XML processing scenario, using it to gauge the complexity of each linking scenario. Please note that the XML Schemas and XPointer technologies used below are still works in progress and lack production-quality implementations. [...] The ability to define links between nodes without modifying these nodes is key for defining links between resources you don't own on the Web. This is one of the reasons why extended XLinks is the technology of choice for topic maps. This ability can be shared by RDF though, and we could have designed our RDF example to achieve this separation between objects and relations -- we could even have used XPointers in RDF. The difference between the extended links and RDF appears to be mostly a subtle difference of focus. RDF focuses on assertions about links; XLink on links carrying assertions."

Hypertext Link Support Requirements for XSL." By Christopher R. Maden. Written originally for the World-Wide Web Consortium XSL Working Group. Revision 0.2, 12 May 1998. Abstract: "The XLink and XPointer specifications provide a level of hypertext functionality that has not previously been available for widespread use. To succeed as a stylesheet language under these new conditions, XSL must address certain styling problems introduced by rich hypertext, including stylistic treatment of link ends and styling of transcluded text." The document represents only [the author's] thoughts on the subject, and has not been voted upon or endorsed by the XSL WG.

[November 22, 1999] "XPath Tutorial." By Miloslav Nic (Department of Organic Chemistry, ICT Prague). November 22, 1999. ['XPath tutorial: XPaths are just wonderful. I really hope that they will be used as much as possible so there is my little contribution to their propagation.'] See also the larger collection of 'Zvon' tutorial materials by Dr. Miloslav Nic.

[December 02, 1999] "A Robots Processing Instruction for XML Documents." By Walter Underwood. [Announcement] posted to XML-Dev. (December 02, 1999). "The robots processing instruction ('robots PI') is a simple mechanism to indicate to visiting Web Robots whether a document should be indexed and whether links in the document should be followed. In HTML documents, the Robots META tag (Koster 1996) serves the same purpose. This differs from the Standard for Robot Exclusion (Koster 1994, Kollar et al 1996) in that the instructions to the robot are in the document itself instead of in a '/robots.txt' file. An author often does not have permission to change the /robots.txt file stored at the root of the web server, but always has permission to change their own document... This spec, if people approve of it, should probably become an appendix to XLink, just like the robots meta tag is an appendix to HTML 4.0."

[March 31, 1999] "An Investigation of XML with Emphasis on Extensible Linking Language (XLL)." By Justin Ludwig. March 23, 1999. An Independent Study Thesis Presented in Partial Fulfillment of the Requirements of the College of Wooster and the Program in Computer Science. Advisor: Dale Brown. Abstract: "This paper describes Extensible Markup Language (XML) documents. It explains how to construct XML documents with Document Type Descriptions (DTDs), XML Namespaces, Extensible Linking Language (XLL), Extensible Stylesheet Language (XSL), and Cascading Style Sheets (CSS) Level 1. Each chapter includes a real-world case study of XML usage related to the chapter. This paper also describes an XML browser that can process and display XLL hyperlinks. It includes a full implementation in Java, using the Document Object Model (DOM) Core Level 1." See the fuller description of Link in the 'software' section. [local archive copy]

[December 16, 1998] "Links in XML: Detection, Representation and Presentation." By Liam R. E. Quin (GroveWare Inc.). Preprint version. Presentation at the Markup Technologies '98 Conference, Chicago, November 1998. Abstract: "The XML language has support within it for HyperText links, and uses links itself to associate disparate components of compound documents. A number of associated standards and recommendations have grown up around XML, and many of these introduce their own forms of linking. Furthermore, there are linking conventions in both computer-based information display systems and in paper-based typographical layout. This paper provides a summary of many of these linking systems, and also attempts to delineate the underpinnings of a unifying abstract model based on the concept of Linking Functions sufficient to describe the links. A single and minimal terminology set is used. Indications are also made of linking forms that are in common use but that XML does not at the time of writing directly support." [local archive copy, preprint version]

[August 03, 1998] "Initial Experiences of an XLink Implementation." By Leslie Carr [Multimedia Research Group, University of Southampton]. "The aim of this work has been to produce a collection of classes that support XLink processing, identifying and resolving the data that is pointed at by the XLink locators, and allowing application-defined semantics to be brought to bear on those combinations of data. The result has been the uk.ac.soton.xlink package, consisting of the XLink, XAnchor, XLinkCollection and XLinkUtilities classes, along with some modifications and extensions to the com.ibm.xml.xpointer package." See also the author's note.

TEI Extended Pointers

HyTime

HTML

Software tools generally applicable to the XML family of languages are referenced in the main XML page, software section.

[March 15, 2002] X-Hive/DB 2.0. "Intelligent linking: "X-Hive/DB includes an XLink compliant linking engine. With X-Hive/DB's XLink engine you are able to offer support for bi-directional links, link-bases and link management. In conjunction with the XPointer implementation, X-Hive offers a pure XML based link Processor... W3C and XML:DB standards: By adopting the latest stable W3C standards and by contributing to the W3C and XML:DB, X-Hive ensures the availability of the latest XML technology to its customers. X-Hive/DB currently supports XML 1.0 with Namespaces, DOM Level 2, XPath, XPointer, XLink, XSL-T, XSL-FO, XUpdate, and XQuery (Q2 2002)."

[February 25, 2002] University of Bologna Test Implementation of XPointer. 2002-02 work in progress. One of "two different implementations of XPointer at the University of Bologna (each one part of a larger project)... The XSLT++ engine is an extended XSLT processor for the generation of meta-information out of a large base of homogeneous XML documents. In our intention, it should match not only nodes of the XML tree, but also arbitrary strings and patterns within the source document. We foresee several extensions, especially for XPointer-based expressions..." See the "very simple interface for an early implementation of XPointer. This work is part of the XSLT++ project, which is being done by Claudio Tasso for his master thesis in Computer Science at the University of Bologna, under the supervision of Fabio Vitali. This program is released as free software under the terms of the GNU General Public License; see source code. The current implementation extends the XPath libraries available with Xalan. The current implementation is not complete yet; for instance, character escaping is not supported at the moment... Try it: Enter a well-formed XML document in the first textarea, and an XPointer query in the text box..." See W3C XML Pointer, XML Base and XML Linking.

From the Third International XBRL Conference in Sydney: Fujitsu gave a presentation on XBRL processing. "...Fujitsu is currently developing technologies for processing XBRL documents, such as instance documents, taxonomies and linkbases. XLink processing technology is a key in processing XBRL documents. Fujitsu has applied its Fujitsu XLink Processor (XLiP) in developing a new technology to support XLink and Xpointer application to XBRL, and this is the first almost complete implementation for XBRL Specification 2.0 in the world... This program is a server-side application which processes XBRL Spec. 2.0 documents. Many programs such as Web browsers can be used as clients of the program, and you can see XBRL documents in the form you like..."

[April 20, 2001]XTooX: A Free XLink Processor.Christian Nentwich (Department of Computer Science, University College London) recently announced the public availability of an open source XLink processor 'XTooX' which supports XLink "linkbase folding." The tool processes 'XLink' links as specified by W3C XML Linking: "An XLink is similar to a link in HTML, but it is a lot more powerful: any element can behave as an XLink (as opposed to just the <a> element in HTML), a link can contain more than two endpoints (effectively linking multiple resources together), and links can be defined out-of-line, that is they do not have to be inside the files being linked. XTooX is a free XLink processor that turns extended, out-of-line links into inline links. It takes as its input a linkbase (i.e., a document containing only XLinks) and puts the links into the referenced documents. If you have a link generator that gives you a linkbase and an XSL processor, you can now produce entire web sites automatically. XTooX originated as a student project at University College London and is now maintained by Christian Nentwich. The original authors are Heenesh Patel, Alberto Ryan, Khalid Bari, Osman Maqsood, Dheraj Dagar, Chee Tan, and Majid Khan. XTooX is free software under the terms of the GNU Lesser General Public License (LGPL). The GNU Lesser General Public License allows you to link XTooX to your product, commercial or free, in its binary form, as a dynamic library." The online demo uses a sample linkbase that links together several XML documents and shows how to use XTooX to get those links into the actual documents. Alternately, you may access the interactive tool and enter a full linkbase URL for processing. [Full context]

[December 17, 1998] Steve DeRose (Brown University, and editor of the W3C's XPointer and XLink Specifications) has posted a provisional listing of 'XPointer/XLink Implementations, and requests that reviewers contact him about additions and corrections to the list. The XML Linking Working Group has been set up (Bill Smith, Chair), and is actively working to finalize the XML Pointer Language (XPointer) Working Draft in preparation for its becoming a W3C Proposed Recommendation. Steve has also prepared an introductory document "What is XML Linking?" which explains the design work of the XML Linking Working Group.

[December 02, 1999] X2X - XML XLink Engine from STEP UK. A posting from Jason Markos describes the release of 'X2X - An XML XLink Engine' by STEP UK. "STEP UK Ltd. announces the beta programme of X2X the XML XLink engine. X2X allows for the creation, management and manipulation of links. X2X allows linking between documents and information resources without needing to change either of the source or target documents that are being linked. X2X removes the requirement to insert link information inside document content. The Links are NOT in the document. X2X has an extensible architecture to allow resources to reside in any data repository. X2X stores links independently of any documents and provides facilities to dynamically insert external link structures into documents on-demand. X2X stores all the link information within a ODBC/JDBC enabled database, e.g., Oracle or SQL Server. X2X is initially developed in Java for cross platform operation. X2X is implemented using fundamental linking concepts and understands links defined using the latest draft of the W3C XLink proposal. This scalable technology delivers the ability to associate different data resources regardless of their location. X2X allows for the retrieval of resources and can dynamically add the external link information without altering the original document/ information. The power of linking has been harnessed to allow structured information objects such as XML to be associated with information lacking structure. The architecture enables organizations to store data in the repository of their choice; while XLink adherence means that link information can be authored using a variety of applications. X2X works independently of the storage, authoring and delivery applications. X2X exposes its powerful functionality allowing it to be integrated into any static or dynamic application or service. With X2X it is possible to deliver richer information streams to users with little or no impact on existing data management procedures. The X2X technology preview is available for download at http://www.stepuk.com/x2x/x2x_dem.asp." See the Overview, the Technical Overview, API Notes, Usage Case #1, Usage Case #2, and the API Guidance - X2X Developer Guide.

[April 20, 2001] "XML projects in Japan and Fujitsu's approach to XLink/XPointer." By Toshimitsu Suzuki and Masatomo Goto (Fujitsu Labs Ltd, Nakahara Ku, Kawasaki, Kanagawa 211, Japan). In Fujitsu Scientific and Technical Journal Volume 36, Number 2 (December 2000), pages 175-184 (with 46 references). [Special Issue on Information Technologies in the Internet Era.] "The Extensible Markup Language (XML) is a markup language developed in response to a recommendation by the World Wide Web Consortium (W3C). It is a meta language used to make an information structure. XML's original specification is the Standard Generalized Markup Language (SGML). Now, XML is used not only as a format language but also as a framework in various areas beyond the SGML field. This paper describes the XML technology trends, the current state of XML technology, and some case studies in Japan and at Fujitsu. The paper also describes HyBrick, which is an XML/SGML browser that was demonstrated at SGML'97, and the XLink/XPointer technology... XML has the dual role of being a document notation and a data exchange format. As described in this paper, XML is mainly used as a data exchange format to access the same data from different kinds of platforms and applications and to execute processing based on this data. New hyperlink applications will conform to this trend. Currently, XSL is popular as a data exchange format, but if it is standardized, its use for document notation or as a substitute for HTML will expand. However, in the current situation, basic HTML technology for hyperlinks remains essential, and XLink and XPointer will become more important in the foreseeable future. Lastly, a few words about Minimal XML. Minimal XML is especially aimed at data exchange and features simple and fast parse processing to eliminate attributes and entity references. Keep an eye on the development of this protocol because it is suitable for use in Electronic Data Interchange (EDI)..." See also Fujitsu XLink Processor. [cache PDF; see also an approximation of the PDF in a cached/rescued version.]

[October 17, 2000] A communiqué from Anthony Finkelstein (University College London, Department of Computer Science) describes the "preliminary technical release" of an XLink generator which the developers characterize as "a completely new class of internet technology." The tool 'xlinkit.com' [previously 'consistencycheck.com'] is a lightweight application service which provides rule-based link generation and checks the consistency of distributed documents and web content. You simply tell 'xlinkit.com' the information you want to link and rules that relate the information. 'xlinkit.com' will generate the links that you can then use for navigation. It will also diagnose inconsistent information (in other words make sure that you are not saying one thing in one place and another completely different thing in another place) and, if you want, provide you links directly to the inconsistent items of information. 'xlinkit.com' will eliminate the work required to directly author links and keep them up to date as well as simplifying the management of the consistency of distributed documents and web content. 'xlinkit.com' can link and diagnose any information expressed in XML and generates XLinks; both are open, non-proprietary internet standards. xlinkit.com is both scalable and highly customisable, you can handle large document sets and build rules of arbitrary complexity using our simple set-based rule language." 'xlinkit.com' can be applied "anywhere that you want to establish links between documents -- or more generally web-content -- where those links reflect relationships between document types. Examples: Customer Relationship Management, Product Catalogues, B2B Service-level Agreements, Requirements Management, Software Development, Software Development, Network Management Policy, Product Data Management." To use the tool one must write rules, and assemble rule-sets and document-sets; all such information is structured in XML. The web site provides the XML DTD for the rule language, together with an XSL stylesheet for visualising the rules. There is also an XML DTD for the rule-set language and a DTD for the document-set language. 'xlinkit.com' is based on an approach that builds on a substantial research background developed by the Software Systems Engineering Group at University College London. This research has been based on the problems of coordinating and managing consistency in distributed software engineering teams. See the publications page of Anthony Finkelstein for pointers. Example documents appropriate for 'xlinkit.com' are provided for anyone wishing to experiment with the application. See www.xlinkit.com. The XLink generator tool is free and open for use for demo or trial application. Also: (1) technical overview, [cache]; (2) plaintext grammar of the rule language, [cache]; (3) DTD of the rule language, [cache]; (4) DTD of the rule-set language [cache] (5) DTD of the document-set language [cache]; (6) XSL stylesheet for visualising the rules, [cache]. There is [2000-10] a servlet architecture; check out Wilbur's bikeshop' (a simple illustrative example of xlinkit.com technology in use).

[February 27, 2001]XLINKIT.COM Demonstrates a UML Checker Using XML and XLink. A posting from Christian Nentwich references an updated online application of 'xlinkit' for software engineering called the 'xlinkit UML Checker': "you can submit your UML document to this service in XMI format; the document will be checked for inconsistencies according to the rules set out in the UML Standard, as defined by the OMG. The well-formedness rules are expressed in the 'xlinkit' rule language, which allows arbitrary first order logic expressions, restricted to equality as the only function and finite sets of DOM nodes as the only type of set allowed." The 'xlinkit' tool represents a "lightweight application service which provides rule-based link generation and checks the consistency of distributed documents and web content. The tool leverages standard Internet technologies, notably XML and XLink. [Full context]

[November 24, 2000] XPointer and XLink support in Amaya. On November 22, 2000 W3C announced the release of Amaya version 4.1, supporting HTML 4.0, XHTML 1.0, HTTP 1.1, MathML 2.0, and many CSS 2 features; it also provides RDF and XPointer/Xlink support in connection with its collaborative annotation system. Amaya 4.X also "includes a collaborative annotation application based on Resource Description Framework (RDF), XLink, and XPointer. From the technical point of view, annotations are usually seen as metadata, as they give additional information about an existing piece of data. In this project, we use a special RDF annotation schema for describing annotations. Annotations can be stored locally or in one or more annotation servers. When a document is browsed, Amaya queries each of these servers, requesting the annotations related to that document.. Amaya uses XPointer to describe where an annotation should be attached to a document. With this technique, it is possible to annotate any Web document independently, without needing to edit that document. Finally Amaya presents annotations with pencil annotation icons and attaches XLink attributes to these icons. If the user single-clicks on an annotation icon, the text that was annotated is highlighted. If the user double-clicks on this icon, the annotation text and other metadata are presented in a separate window..."

[November 03, 2000] Fujitsu XLink Processor. Developed by Fujitsu Laboratories Ltd., as "an implementation of XLink and XPointer. This processor supports XML Linking Language (XLink) Version 1.0 Candidate Recommendation. You may use this processor and other included programs without charge for 60 days after the installation. You must read 'LICENSE', before you begin your installation..." Multi-Platform: Developed with Java, this processor can be used on many platforms which support Java Runtime Environment. Support for XLink Ver.1.0CR: This processor supports XLink Ver.1.0CR, which is now being discussed in W3C. XLink/XPointer processing with DOM: This processor works with DOM. This processor can work with any XML processor or parser which can create DOM, on condition that an appropriate interface between this processor and it is implemented. Supported Features: XLink Features: simple-type element and its related attributes extended-type element and its related attributes locator-type element and its related attributes resource-type element and its related attributes arc-type element and its related attributes title-type element, Linkbases. XPointer Features: Bare Names, Child Sequences. Links: demo application; download; license. Contact: xlp@ml.fujitsu.co.jp or Masatomo Goto.

[September 18, 2000] XPath Visualiser. "This is a simple yet powerful tool for the evaluation of an XPath expression and visual presentation of the resulting nodeset. You type in your XPath expression and the returned nodes are highlighted, allowing you to experiment with XPath for finding the correct expression." By Dimitre Novatchev. See the overview and README. See also XPath Visualiser: September [2000] MSXML parser release support - "This is an upgrade to the original Visualiser download, which now supports the September MSXML Parser. Other new features are: 1. Namespace axis support. 2. Detecting and hi-lighting collapsed elements that contain some hidden selections. Visualiser download, which now supports the September MSXML Parser. Other new features are: 1. Namespace axis support. 2. Detecting and hi-lighting collapsed elements that contain some hidden selections..." download, [cache]

[October 16, 2000] Gnome XML Library's libxml-2.2.5 Supports XPointer and XPath. Daniel Veillard (W3C) posted an announcement for the release of libxml-2.2.5 in the Gnome XML library with XPointer and XPath implementations, including an initial testsuite. "I usually don't post announces of new releases of libxml to xml-dev, but this this version has XPointer support which was requested previously here I think it makes sense: Libxml is the XML C library developped for the Gnome project, it allow to parse, manipulate, and save XML and HTML documents but it does not expose a GUI interface. Here are some key points about libxml (a.k.a. gnome-xml): (1) Libxml exports Push and Pull type parser interfaces for both XML and HTML. (2) Libxml can do DTD validation at parse time, using a parsed document instance, or with an arbitrary DTD. (3) Libxml now includes a nearly complete XPath and XPointer implementations. (4) It is written in plain C, making as few assumptions as possible, and sticking closely to ANSI C/POSIX for easy embedding. Works on Linux/Unix/Windows (5) Basic support for HTTP and FTP client allowing to fetch remote resources (6) The design is modular, most of the extensions can be compiled out. (7) The internal document repesentation is as close as possible to the DOM interfaces. (8) Libxml also has a SAX like interface; the interface is designed to be compatible with Expat. (9) This library is released both under the W3C IPR and the GNU LGPL; use either at your convenience. URLs for libxml include http://xmlsoft.org/ and ftp://xmlsoft.org."

[April 03, 1998] Alpha/snapshot - Eliot Kimber's 'XLink in DSSSL Package', with an interface that "lets you test your XLink documents using the DSSSL XPointer implementation." Provides a function package for resolving XPointers in DSSSL using Jade. Alpha sources. . . "implemented the four absolute terms and all the relative terms except preceding, which has a bug somewhere in its supporting functions. I have not yet implemented attribute qualification or the 'other terms' (span, string, attr). . ." - as reported on DSSSList, and then more completely on XML-DEV. Work in progress report, 19980416.

[April 03, 1998] See also Kimber's "Test Your XPointers" - "Lets you test your XLink documents using the DSSSL XPointer implementation. When you submit a document you will get back a report of the results of attempting to resolve all of the XPointers in your document.Documents must be accessible over the Web (not just on your local machine).

[August 27, 1999] [Reopened HyBrick Web site.] HyBrick SGML/XML Browser. "HyBrick" is an advanced SGML/XML browser developed by Fujitsu Laboratories, the research arm of Fujitsu. "HyBrick" is based on an architecture that supports advanced linking and formatting capabilities. HyBrick includes a DSSSL renderer and XLink/XPointer engine running on top of James Clark's SP and Jade.

[March 04, 1999] Ralph E. Ferris (Fujitsu Software Corporation) has announced a new release of Fujitsu's HyBrick SGML/XML browser, with expanded support for XLink/XPointer. It is available from the Fujitsu Software Corporation's Web site. New features in HyBrick V0.82 related to XLink and XPointer include: "1) XLink/XPointer error/warning info is shown in the error list dialog; 2) A 'Document Group' sub-menu has been added in the 'XLink/XPointer' menu; users can now navigate between inter-linked documents by using Document Groups as well as through individual links; 3) In the 'select link' dialog, link element 'role' values are displayed instead of GIs. This feature, as well as the 'Document Group' display feature, are particularly useful for creating and navigating 'Topic Maps.'; 4) The mouse cursor now changes its shape over links." Also new in HyBrick 0.82 are multiple stylesheet support (if multiple stylesheet PIs are present, users are presented with a dialog box to select the stylesheet they want to use), 'Reload hubdocument' function and 'Close window' function. 'HyBrick' is "an advanced SGML/XML browser developed by Fujitsu Laboratories, the research arm of Fujitsu. 'HyBrick' is based on an architecture that supports advanced linking and formatting capabilities. HyBrick includes a DSSSL renderer and XLink/XPointer engine running on top of James Clark's SP and Jade. It supports both valid and well-formed XML documents, XLink and XPointer (XLink implemented as a subset of the HyTime property set), SGML (ISO 8879), DSSSL (ISO 10179) online specification, printing and print previewing based on DSSSL stylesheets." See more on HyBrick Support for XPointer in a posting of March 4, 1999.

[August 14, 2000] Reusable XLink XSLT transformations. By Fabio Arciniegas A. "XLink2HTML is a set of XSLT stylesheets for the creation of HTML representations of Xlink elements. It is particulary useful to represent one-to-many arcs from local resources to locators. However, other relationships possible in an inline xlink element are implemented. XLink2HTML doesn't have linkbase or behavioral attribute support (i.e. only replacement for the moment). Finally, it is worth noting that the correct representation of an xlink is ultimately dependant on the semantics of each arc. XLink2HTML is only a representation, based on the common problem of presenting multi-ended XLinks as something similar to <a href when translating XML documents to HTML." download, [cache]

[November 16, 1999] A posting from Takuki Kamiya (Fujitsu Ltd.) announces the availability of an XPath interface for XT Version 0.85'. The author says: "I have written an DOM query utility in Java on top of XT. It is implemented in Java language and complies with W3C's XPath Proposed Recommendation as it is currently implemented in XT. You can use it to retrieve DOM Nodes that matches to a given XPath selector. To use XPath interface for XT Version 0.85, [one would]: (1) Build a DOM Tree (i.e., org.w3c.dom.Document) by using a XML Parser; (2) Construct a DomQueryManager object with the DOM created in step '1'. (3) Invoke DomQueryManager's getNodesByXPath method by supplying a DOM Node and XPath selector string as arguments. I share the code with the community for free to see if anyone finds it useful... Free with no warranty. Comments are welcome. Any feedback is invited."

[July 17, 2000] A Toolkit for Advanced XML Browsing Functionalities. Projektarbeits-/Diplomarbeitsthema, by Michael Kraus; Institut für Informatik der Ludwig-Maximilians-Universität München. "The goal of the work is to conceive and to implement a browser toolkit for XML. The objective is to use the toolkit to implement and test various advanced browser functionalities. Within the current project, the following functionalities will be implemented and tested: (1) Various presentation modes for the hyperlinks of XML; (2) A so-called 'readers view' enabling a user of the browser to annotate the document visited and to some extent to restructure it, e.g. so as to record the way the document was visited. These functionalities are discussed in more detail below. The work outlined here is part of the project 'Data Modeling with Markup Languages', in particular see part 3.1 'Hyperlink Model vs. Browser Model -- Hyperlinks for Semantic Modeling'.

4XLink from Fourthought.com. "4XLink is an extended link tool kit. The W3C working draft of the extensible linking language describes a sophisticated system for linking XML objects. 4XLink provides a framework for processing such links. 4XLink will soon be available to the public. [2000-10-02]

[June 18, 1998] XPointer support in IBM XML for Java, version 1998-06-12 (with an XPointer sample application): "XPointer package com.ibm.xml.xpointer package provides parsing XPointer expression, generating an XPointer instance from a node in a document tree, searching for nodes pointed by an XPointer instance. [. . .] In the XPointer Demonstration: Click a node: (Display an XPointer expression of clicked node on a text field); Put an XPointer expression and press "Go" button: (Select nodes pointed by the XPointer.)"

[November 12, 1998] Simon St. Laurent posted an announcement "Creating an Open Source XLink SAX Parser Filter" which describes preliminary work on an XLink Filter, and invites contributions/comments. "The XLink Filter Project is attempting to create a layer that can rest between a SAX-compliant parser and Java applications that uses the SAX API to retrieve information from XML documents. The XLink Filter will be an open source software project, built using Java. The XLink Filter project hopes to provide support for the entire XLink specification, and provide sample applications that implement the actions involved in linking. Initially, the filter will support simple and extended links between documents that have been visited by the user; eventually, it will provide support for extended hub groups to allow pre-fetching of links." See also the XLinkFilter Resources.

[August 24, 1998] David Megginson posted an announcement for "XPointer Support for PSGML/Emacs." Implemented as a module psgml-xpointer.el, this is a short add-on function for PSGML that automatically generates an XPointer for any location in an XML or SGML document. The program will climb the element tree until it finds an element with an ID attribute, then will use child() statements to locate the closest element that contains the point." See David Megginson's software tools for a link to this utility. [local archive copy]

[March 31, 1999] Justin Ludwig completed an independent study project in Computer Science at the College of Wooster on the W3C's XML, XSL, and XLL markup specifications. He has also implemented a general XML browser application in Java for this project; it allows a user to traverse the simple and extended links of the first XLL specification. The author hopes that this application might add a little insight into how XLinks and XPointers might actually be implemented. The tool is 'Link - an XML-XSL-XLL browser'. "Link is a simple application written in Java that allows a user to view XML documents with XSL stylesheets and XLL hyperlinking. It uses several third-party Java libraries, including the Docuverse DOM implementation, James Clark's XP parser and XT XSL processor, and the XML-DEV mailing list's SAX API. The paper portion of this project ("An Investigation of XML with Emphasis on XLL") describes the markup details of XML, XSL, and XLL, as well as some of the workings of Link's Viewer class. Link renders documents with XSL stylesheets that contain HTML formatting only, and not the formatting objects described in the XSL specification. It allows traversal of both simple and extended XLinks, recognizing the xlink:form, xlink:href, and xlink:title attributes. It treats all links as if they had xlink:actuate="user" and xlink:show="new" attributes." The Link tool is available for download. [local archive copy]

[September 11, 1998] "Xlink and Groves" (alias, "Grove-based XLink Implementations") delivered at the XML Developers' Conference, August 20-21, 1998. Kimber gave a demonstration of PHyLIS, Personal HyTime Link Information System, [which is] an attempt to implement the HyTime standard using componentized software techniques (ActiveX). PHyLIS uses a literal grove-based approach and demonstrates the ability to apply XLink, SGML architecture (AFDR), and HyTime processing to XML documents in a completely standards-based environment. PHyLIS is designed to be an open integration platform that is infinitely extensible." Presentation slides for "Grove-based XLink Implementations" are available online. See www.phylis.com for details, including source code.

[July 18, 1998] Patrice Bonhomme: "The XPointer parser has been integrated in a complete XML toolkit entirely developped in Java comprising an XML validating parser and an XML Java API. Both XML and XPointer parsers are developped using the Java Parser Generator, JavaCC. The Java API is developped with the JDK 1.1. The release 0.5 is available from the XSilfide web site http://www.loria.fr/projets/XSilfide/EN/index.html. [ . . .] "I have developed an XML Parser in Java and a tree based API which works fine. I have implemented the whole XML 1.0 (REC 10-02-1998), the XML Namespaces (WD 27-03-1998, the Document Object Model Level 1 (DOM Core and XML, WD 16-04-1998) and both XML links and XML pointers."

[May 07, 1998] Lars Marius Garshol: "I'm currently writing a toy XPointer implementation in Python (which will quite possibly become serious later) and have to say I'm impressed with the XPointer specification. Very clear descriptions and a nice syntax." (See the posting/reply on XML-DEV.) See below.

[July 24, 1998] From Lars Marius Garshol: PyPointers: A Python XPointer implementation. Version 0.20 released August 2, 1998. "PyPointers is an implementation of the XPointer locator language used to locate specific points and areas in XML and HTML documents. It consists of a general parser and an implementation that locates DOM nodes. (The DOM locator uses PyDOM to build a DOM tree.)" PyPointers is part of a larger project, "Tools for Parsing XML with Python," itself "a part of the ongoing effort to make Python the language of choice for XML processing." See further at: xmlproc: A Python XML parser.

December 01, 1998. Ralph Ferris of Fujitsu Software Corporation posted an announcement for a new XLink/XPointer Developer's List. The email forum has been launched "in order to promote wide discussion of XLink/XPointer development issues." To subscribe to the new xlxp-dev list, send an email message to majordomo@fsc.fujitsu.com with the following in the body of the message: subscribe xlxp-dev. Messages are archived. Other mailing lists dedicated to XML and related markup technologies are referenced in the master list of "SGML/XML Discussion Groups and Mailing Lists."

[August 28, 1997] Steve DeRose on TEI Extended Pointers vs XLL linking (XLink). Clarifies the relationship between TEI xptrs (as defined in P3) and the XLL linking, where great pains were taken in the XLL design "to avoid any syntax which would exist in both variants of xptrs but have different meaning."

[October 16, 1998] At the SGML/XML Europe '98 conference, Masatomo Goto (Researcher, Fujitsu Laboratories Ltd, Japan) presented "An implementation of XLL as a subset of HyTime." It described an approach to the implementation of the Extensible Linking Language (XLL) as a subset of HyTime and presented an application design using the XLL engine.

[December 22, 1998] XArc (a.k.a. XLink--++) - From Gabe Beged-Dov (JFinity Systems), December 21, 1998 or later. For general information, see the XArc Home Page. "XArc is a very simple specification for describing directed labeled graphs in XML. The XArc construct provides the minimal support necessary for this task. Using XArc it is then possible to emulate both the XML Linking Language (XLink) and the Resource Description Framework (RDF). Simon St. Laurent's XLinkFilter is being migrated to make use of XArc in its next generation version. "