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.

Bibliographic Information

XML Indirection Facility. Edited by W. Eliot Kimber, ISOGEN International, LLC. W3C Note. 12-June-2003. First public version. Version URL: http://www.w3.org/TR/2003/NOTE-XIndirect-20030612. Latest version URL: http://www.w3.org/TR/XIndirect.

Details from the XIndirect Introduction

The XLink and XPointer specifications provide a complete solution for the delivery of XML-based hyperdocuments. XLink and XPointer explicitly avoid indirect addresses. This is the appropriate design choice for delivery. In a delivery environment it is essential to avoid any unnecessary processing or complexity. Indirection adds significant potential complexity to the processing of hyperdocuments. Indirection is not required for delivery because the documents as delivered can reflect a more-or-less static data set in which all pointers can be hardened to direct references. This is especially true when the delivery context may be an essentially unbounded system, such as the World Wide Web.

However, for authoring, indirection is required in order to make it possible and practical to manage pointers as new versions of documents are created. Authoring systems are usually closed systems with a much smaller local scope than the intended delivery environment. In such closed systems the use of indirect addressing is both practical to implement and necessary in order to solve certain problems in pointer maintenance for versioned hyperdocuments.

This document proposes a simple mechanism for using XML to represent indirect addresses. The facilities defined in this Note augment the core functionality of XLink and XPointer without requiring either of those specifications to themselves require support for indirect addresses. This lets document and management system designers decide when indirection is necessary.

From the W3C Team Comment on the XIndirect Submission

"XIndirect is a way of representing indirect addresses (pointers). In other words, it is a way to write links in XML where the target of a link is determined from data held in separate part of the document from the actual link itself. Extensive experience in the SGML industry showed that this sort of indirection can be very beneficial, espcially in large-scale document management.

XML already has an indirection facility which could be used in links: internal text entities. Reasons for defining a new facility which does not make use of entities might include:

• Since entities are replaced by their content during XML parsing, they are fragile: they may not survive a cycle of editing a document and then saving it.
• Not all uses of XML support the definition of XML entities; for example, SOAP payloads cannot define them.
• XIndirect is a way to represent the fact of indirection in markup: it is semantic, whereas an approach using entities is syntactic... [adapted from Liam Quin's comment document]

XIndirect: Eliot Kimber's Reflections

XIndirect is driven almost entirely by the requirements of document authoring, in particular, the authoring of systems of connected documents. The XInclude facility, in particular, makes the need for indirection more compelling because it both enables the easy creation of compound documents using a W3C specification and does not, by itself, provide any indirection mechanism, which you clearly need when you are authoring documents that are distributed among many users, systems, management systems, and so on. As I started using XInclude in authorign and production systems instead of the HyTime-based use-by-reference mechanisms I'd used in the past, I started to realize that the lack of indirect addressing was a serious limiting factor in my ability to support a number of authoring and document management use cases using only W3C-defined, XML-based facilities.

Essentially, the Web's architecture assumes that a given resource is always available from a particular server -- it isn't expected to move to a different URL. This is a reasonable simplifying assumption for read-mostly documents, which characterizes most Web site content. But it is not reasonable for write-mostly documents, that is, documents being actively authored. In addition, document authoring is usually done within the confines of closed systems with relatively limited scopes. In these systems, the simplifying features of the Web are not needed in order to keep things managable.

For information management, indirection is key. For hyperdocument authoring, indirection allows you to protect initial references from their eventual targets, so that changes to the locations of targets does not necessarily require a change to the documents that point to the targets. It allows you to automate the tracking and management of address changes as resources move about in the system, for whatever reason (for example, going from inside the central database to a client machine during an editing session, or from the authoring repository to the delivery server).

Having gone through the experience of helping develop both HyTime and XML I came to understand that while indirection facilities are absolutely needed for authoring, a very lightweight solution will meet those requirements. In other words, I realized that I could ignore all the complicating features of HyTime and define a very simple mechanism that would be sufficient unto the task. Such a facility would be able to take advantage of all the supporting infrastructure, such as XPointers, that the XML family of standards already provides. I knew it would be relatively easy to implement, especially if XPointer processing is readily available. In essence, I was able to distill almost 15 years of hyperdocument management experience and thinking to about 5 pages and 2 element types (one of which is merely a convenience). It was a humbling realization.

One key characteristic of XIndirect is that it is entirely optional -- it does not impose any additional processing requirements onto existing linking and addressing facilities (XPointer, XLink, XInclude) in order to be useful. Rather, it allows system implementors to decide when and if indirection is useful and implement it or not. The rest of the system can be completely unaware that indirection is even happening. For delivery, all indirect addresses can be hardened into direct references, meaning that generic Web servers need never worry about resolving indirect addresses.

This allows the processing and management of indirect addressing to be limited to those processing environments where it is really needed.

Note: This text supplied by W. Eliot Kimber (Consultant, ISOGEN International LLC) on Friday, 13-June-2003 01:38:55 +0300)