web_development

When to use XML

From W3C’s “Architecture of the World Wide Web, Volume One“:

XML defines textual data formats that are naturally suited to describing data objects which are hierarchical and processed in a chosen sequence. It is widely, but not universally, applicable for data formats; an audio or video format, for example, is unlikely to be well suited to expression in XML. Design constraints that would suggest the use of XML include:

1. Requirement for a hierarchical structure.
2. Need for a wide range of tools on a variety of platforms.
3. Need for data that can outlive the applications that currently process it.
4. Ability to support internationalization in a self-describing way that makes confusion over coding options unlikely.
5. Early detection of encoding errors with no requirement to “work around” such errors.
6. A high proportion of human-readable textual content.
7. Potential composition of the data format with other XML-encoded formats.
8. Desire for data easily parsed by both humans and machines.
9. Desire for vocabularies that can be invented in a distributed manner and combined flexibly.

The original description of Ajax

From Jesse James Garrett’s “Ajax: A New Approach to Web Applications“:

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

  • standards-based presentation using XHTML and CSS;
  • dynamic display and interaction using the Document Object Model;
  • data interchange and manipulation using XML and XSLT;
  • asynchronous data retrieval using XMLHttpRequest;
  • and JavaScript binding everything together.

The classic web application model works like this: Most user actions in the interface trigger an HTTP request back to a web server. The server does some processing — retrieving data, crunching numbers, talking to various legacy systems — and then returns an HTML page to the client. It’s a model adapted from the Web’s original use as a hypertext medium, but as fans of The Elements of User Experience know, what makes the Web good for hypertext doesn’t necessarily make it good for software applications. …

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.

Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something. …

Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.

Create web sites with PONUR

From “Dive Into Mark“:

Web Content Accessibility Guidelines 2.0 working draft from April 24, 2002. Only 3 weeks old!

The overall goal is to create Web content that is Perceivable, Operable, Navigable, and Understandable by the broadest possible range of users and compatible with their wide range of assistive technologies, now and in the future.

  1. Perceivable. Ensure that all content can be presented in form(s) that can be perceived by any user – except those aspects of the content that cannot be expressed in words.
  2. Operable. Ensure that the interface elements in the content are operable by any user.
  3. Orientation/Navigation. Facilitate content orientation and navigation
  4. Comprehendible. Make it as easy as possible to understand the content and controls.
  5. Technology Robust. Use Web technologies that maximize the ability of the content to work with current and future accessibility technologies and user agents.

I like that: perceivable, operable, navigable, understandable, and robust. That deserves to become a new acronym, PONUR

SSL in depth

I host Web sites, but we’ve only recently [2004] had to start implementing SSL, the Secure Sockets Layer, which turns http into https. I’ve been on the lookout for a good overview of SSL that explains why it is implemented as it is, and I think I’ve finally found one: Chris Shiflett: HTTP Developer’s Handbook: 18. Secure Sockets Layer is a chapter from Shiflett’s book posted on his web site, and boy it is good.

SSL has dramatically changed the way people use the Web, and it provides a very good solution to many of the Web’s shortcomings, most importantly:

  • Data integrity – SSL can help ensure that data (HTTP messages) cannot be changed while in transit.
  • Data confidentiality – SSL provides strong cryptographic techniques used to encrypt HTTP messages.
  • Identification – SSL can offer reasonable assurance as to the identity of a Web server. It can also be used to validate the identity of a client, but this is less common.

Shiflett is a clear technical writer, and if this chapter is any indication, the rest of his book may be worth buying.