Peter F Brown - Information Architecture

Introduction

XML must be understood in the context of the 'Web paradigm': by this, we must understand the set of technologies and information management practices that have led to the explosion of the so-called World Wide Web.

This paradigm has broken down previously existing barriers between computing platforms and applications that manipulate data, by providing a high level of interoperability across heterogeneous systems through the use of three key standards:

• TCP/IP, an already well-tried and tested protocol for transmitting data across the Internet;
• HTTP, a protocol that manages the transfer of a file from a server to a client in response to requests from a client; and
• HTML, a coding scheme for packaging and labelling information within such files for display on the client's screen.

The robustness of these standards led many organisations to replicate the same concept, as a way of overcoming similar problems of incompatibility across different platforms.

As such, the paradigm has led to much more than just an explosion of public Web sites from 1994 onwards, but to the ubiquitous presence of these technologies within the enterprise.

HTML on Steroids?

HTML - the language of the Web - is however of limited expressive power and, very soon, was starting to be used more as a conveniently standard 'wrapper' around an increasing volume of proprietary or application-specific code and content. HTML had to evolve, rapidly, or face a "balkanisation" as different vendors pursued divergent strategies to encourage users of the suitability of their 'HTML extensions'.

XML was developed as an answer to the straightjacket that many developers had began to feel HTML represented, whilst attempting to preserve the interoperability and open approach that has characterised HTML. It is understandable therefore in this context that XML is seen as an extension of HTML - sometimes described as 'HTML on steroids' - with a focus on Web environments and Web publishing.

However, XML is much, much more. When listening to an XML proselyte, you will often hear a list of benefits that is certainly impressive and important to any enterprise, including:

• 'content repurposing': the capacity to generate information content in multiple outputs and in multiple formats and media from a single source;
• massive reduction in production on-costs and publication turnaround time;
• 'future protection': the guarantee that, whatever delivery mechanism or format is thrown at you in the future, that you will still be able to deliver from the same single source;
• dramatic improvements in 'intelligent', and thus less wasteful, searching for content;
• the simple reusability of content in different contexts;
• the easing of content exchange between heterogeneous information systems;
• better management of content production at source, implying reductions in downstream problems;
• greater possibilities of automation in workflow systems and ease of adaptability.

Much more than HTML

All of these claims, and many others, are certainly true. In addition, the immediate beneficiaries of a full-blown XML-centred information management system would be those that are involved in:

• the production of large, well-structured, works such as technical and reference manuals;
• managing documents that contain complex structures or involve many interlocking elements and dependencies;
• high volume, often repetitive information exchange.

Sceptics would argue - and have argued - that large undertakings have sufficient resources to develop whatever they want, and according to their absolutely and finely defined criteria. What could be the incentive for them, therefore, to 'compromise' their information systems by using a standard or a technology defined by someone else?

The question, therefore, 'what can XML offer' is a false one precisely because the principal concern of XML is not what but rather how. The 'how' can be summed up easily:
XML offers a means of managing information in a standardised manner that guarantees interoperability and stability over time, and avoids proprietary lock-in.
It is important to remember that XML is designed to be directly useable on the Web:

• XML is character-based and not binary, and as such accessible to humans and the simplest text processor and not just the application that generated it. Put more crudely, you have complete ownership of your content, something that is not true when the content is dependent on a proprietary standard;
• XML uses the main, tried-and-tested, protocols that drive the Internet and the Web, TCP/IP and HTTP. Again, as those standards are public domain, you will not have to worry about the cost of keeping your information moving around, as was the case in many 'EDI' initiatives that relied on proprietary and private networks;
• XML is sufficiently similar to HTML as to represent a low entry point and low learning curve to new users, unlike other 'heavyweight' and vendor-specific systems;
• All the XML family of standards, with a couple of rare exceptions, use the same grammar and syntax. This means that a developer working with one XML application and vocabulary can be 'recycled' very easily into another area without a high learning curve;
• XML can be rolled out with low overheads and short design-to-delivery cycles.

What more?

As XML has grown on the coat tails of the Web, it will be valuable to examine how the 'maturing Web' has highlighted some major management questions that are equally applicable to the development and use of XML.

This is what my book Information Architecture with XML set out to do. More follows...