W3C

Extending XLink 1.0

W3C Working Group Note 27 January 2005

This version:
http://www.w3.org/TR/2005/NOTE-xlink10-ext-20050127/
Latest version:
http://www.w3.org/TR/xlink10-ext/
Editor:
Norman Walsh, Sun Microsystems

Abstract

This document describes some useful changes that could be incorporated into an XLink 1.1 Specification.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is a W3C Working Group Note, made available by the W3C XML Core Working Group as part of the XML Activity. The authors of this document are the XML Core Working Group participants.

This WG Note is being published for information purposes only. The Working Group does not plan to issue updates and therefore has no current plans or process by which to handle feedback.

Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Table of Contents

1 Introduction
    1.1 Proposed Changes

Appendix

A References


1 Introduction

Since its introduction as a Recommendation, [XLink] has been adopted by several markup vocabularies. However, the current trend to migrate from DTD-based validation to schema-based validation poses additional challenges that could hamper its continued adoption.

A few small changes could:

1.1 Proposed Changes

  1. Make simple XLinks an application-level default.

    In XLink 1.0, all simple links must be identified explicitly with an xlink:type attribute. When XLink 1.0 was developed, it seemed reasonable to depend on DTD validation to provide this default value when it was a burden to authors to enter it by hand. As XML use has spread and new validation technologies have been developed, this is no longer the case.

    Rather than relying on an annotation to provide the simple link type, it seems prudent to make this an application-level default. In other words, any element with an xlink:href attribute that does not specify a link type should be treated as a simple link.

  2. Reserve all attributes in the XLink namespace.

    The current XLink 1.0 Recommendation defines several attributes in the XLink namespace. It seems prudent to explicitly reserve all other such attributes for future use. By a strict interpretation of the current specification, authors and other end-users have free latitude to use new attributes in the XLink namespace and this was never intended. Such use would create interoperability problems and should be prohibited.

  3. Allow IRIs.

    The current specification requires that URIs be used to identify some XLink properties, such as role and arc types. In the interest of forward compatibility, these requirements should be amended so that IRIs are also allowed.

  4. Provide Sample XML Schema and RELAX NG Grammars.

    The current specification provides a non-normative sample DTD. Given that XML Schema and RELAX NG are now widely deployed, it makes sense to provide equivalent, non-normative XML Schema and RELAX NG Grammars.

XLink is not without its critics and it's clearly the case that these changes do not address all of the criticisms that have been leveled at XLink. But these changes would make XLink more useful in the places where it is already being used and would make XLink practical in a variety of similar vocabularies.

A References

XLink
XML Linking Language (XLink) Version 1.0. DeRose, Steve, Eve Maler, and David Orchard, editors. World Wide Web Consortium, 2001. (See http://www.w3.org/TR/xlink/.)