72 hours and counting

It occurred to me this morning that Loosely Coupled's web servers run on Eastern time, so they're probably running on diesel generators right now. I don't know the precise location of the data center — why should I? That's up to my hosting provider, Jumpline — but I do know that it's in a Qwest CyberCenter, and a quick look at the Qwest network map indicates that New York is the most likely location, with Newark, Atlanta and Tampa as secondary possibilities.

Qwest says it equips its CyberCenters with "redundant stand-by generator power supplies, in the event of a power failure from commercial power," but it doesn't say how long those (normally diesel-fuelled) generators are designed to stay operational. Normal practise when world-class hosting facilities like these were built was to have enough diesel fuel stored on-site to run for 72 hours — ie three days — but that's an approximate figure, and it's based on a set of assumptions that may no longer apply.

Although the authorities are saying power may not be restored to some areas until the end of the weekend, it seems unlikely that major data centers are going to be at the back of the queue. So the 72-hour limit isn't likely to be tested (at least, not this weekend, although if there's another outage before the fuel tanks get replenished, that's another matter). What may get tested, though, is whether those reservoirs really do hold enough fuel to last for three days.

Most hosting facilities were designed and built at least three years ago. Certainly, no one builds them today, with so much overcapacity around. But in the past three years, there have been enormous advances in blade server technology, which means many more devices can be crammed into a data center. Meanwhile, consolidation has led operators to shut down many facilities, concentrating more servers into those that remain operational. No wonder Qwest doesn't say how long its stand-by power generators will run for. The quantity of fuel available is limited by the physical size of the storage tanks built several years ago. But the power required to keep all those high-speed blade servers functioning has increased substantially since the facility was built.

Reducing the margin of safety for standy-by power probably didn't seem a big risk to take. Before last night, there hadn't been a major power grid failure since 1977. Even in the midst of California's power crisis, outages were fairly localized, and were limited to a few hours at a time. Today, though, the stand-by power reserves of data center facilities in the New York area are facing the severest test in the history of the Internet. How long will those stand-by reserves last? If the power stays off for much longer, we may find out sooner than we'd like.
posted by Phil Wainewright 2:51 AM (GMT) | comments | link

Semantic shift

Tim Bray has done a brilliant job of encapsulating the factors surrounding markup language that create what I'm calling the Babel Paradox (which, in a nutshell, is that speaking the same language as someone else doesn't necessarily imply you'll understand each other).

Tim, who is one of the original co-authors of XML, points out that the meaning ("semantic weight") of any lexical item, such as a markup tag, comes from one of two sources:

1. Assertion by the original author


2. Consensus arising within the user community

He goes on to show that (1) always prevails until people start using the item, in which case (2) takes over, and either sticks with the original meaning or changes it. I would add that, the more widely the item is used, the more likely it is that its meaning will not only change ("semantic drift"), but also diversify in the way it is understood by different groups of users — especially if it's more actively used within those separate groups than across the mainstream population.

"At the end of the day, markup is just a bunch of labels," Tim concludes. "... we shouldn’t try to kid ourselves that meaning is inherent in those pointy brackets, and we really shouldn’t pretend that namespaces make a damn bit of difference."

I think the underlying point here is that we shouldn't try and make human phenomena like language behave in a mechanistic way, because the world doesn't work like that. Meanings don't stand still (and we should never wish them to, because then innovation would stop too). Therefore any machine-readable system of semantics — which is what XML namespaces aspires to become — has to be designed to accommodate semantic shift, rather than imagining that we can achieve a perfect world in which it doesn't exist.
posted by Phil Wainewright 3:49 AM (GMT) | comments | link

How InfoPath works

A new article from MSDN magazine gives a detailed but very approachable introduction to InfoPath, the new Office 2003 add-on that will make it easy to create forms to handle XML-formatted data. It illustrates just how appealing InfoPath will be as a handy tool for accessing and editing data from XML files and web services:

"One of the main benefits of using an InfoPath form over a traditional Web form is the rich functionality offered by the runtime environment. For example, InfoPath provides automatic spell checking while you fill out a form ... It provides real-time validation against the form's underlying XML Schema definition ... InfoPath also offers other advanced features like autocomplete, find and replace, drag and drop, and complete printing support. Generally speaking, working in InfoPath feels just like you're working in any other Microsoft Office product."

It seems that most users will create forms from existing XML sources:

"InfoPath provides an easy-to-use WYSIWYG interface for designing new forms that can be based on XSD or WSDL ... When you select New from the Data Source menu, the Data Source Setup Wizard appears and prompts you to select the type of data source you want to use ... InfoPath reads the available metadata from the data source and displays it in the Data Source view. You can then drag and drop data source fields onto the form as you're designing it."

The only source of major complexity for business users will be creating a mechanism to handle form submissions, which will require access to programmable functionality at the receiving server. But since InfoPath creates forms that can maintain their own state when saved locally, many users will be able to palm off that responsibility to somebody else:

"The form can be submitted to a Web Service, to a virtual directory on a Web server, or via custom script code. It's also possible to submit the completed form via e-mail by selecting File | Send to Mail Recipient. When you do this, InfoPath attaches the XML document to the e-mail and adds the HTML of the view you sent to the body of the e-mail ..."

One of the cunning aspects of InfoPath from Microsoft's point of view is its ability to add functionality that's only available to form users when viewing the form in InfoPath. So although an InfoPath-created form can be uploaded to a web server and accessed from within any browser, you need to be an InfoPath user to get all of the advanced functionality:

"InfoPath has a variety [of] other advanced features ... Rich text controls are mapped to XHTML in the underlying XML document ... Optional sections can be hidden and displayed on demand ... Repeating sections (or repeating lists/tables) let you repeat blocks of information that occur multiple times in a schema. InfoPath also enables you to bind repeating controls to external data sources for automatic population of the control ... Finally, InfoPath provides more advanced validation features than XML Schema provides ..."

No wonder Microsoft seems to be de-emphasizing browser development these days. Any organization that adopts InfoPath for XML forms handling isn't going to want their users accessing those forms via their browsers and losing all that extra validation and content control. Thus InfoPath is an important weapon in the campaign to make Office the preferred environment for accessing web resources, in preference to any standard web browser.

The one thing that InfoPath doesn't do is provide support for users in creating the XML Schemas (or even web services) that InfoPath interacts with. It's all very well providing a rich editing environment for manipulating data, but how will users know whether the data means what they think it does? (the Babel Paradox again). Microsoft's hidden agenda here, of course, is that it will be providing its own XML Schema as part of Office 2003, so everyone will be able to standardize on that, thus eliminating the potential for a proliferation of conflicting XML vocabularies.

No doubt Microsoft defends this grand plan to cement everyone's dependence on its own implementation of XML as a public-spirited contribution to global standardization of electronic business communications. But the flaw in its plan is the problem of interpretation. The right way to accommodate the inevitable cultural nuances and differing practices that exist at individual regional, vertical-industry or even departmental levels is to empower users to add their own selection of properly documented extensions to the core XML Schemas. The harder that is for users to do (and the less understanding they have of the principles involved) the more likely they are to opt for the wrong way — circumventing the difficulty by imposing their own deviant interpretations on the existing XML Schema definitions.
posted by Phil Wainewright 1:59 AM (GMT) | comments | link

Echo of Babel

A topical illustration of the Babel Paradox is the (not) Echo project, an open initiative to create an alternative to RSS that will not only syndicate but can also be used to archive and edit "episodic" web sites such as weblogs. Here we have an impassioned group of people all apparently using a common language in pursuit of a shared objective, and yet they cannot even reach agreement on what to call the project.

The originally suggested names, Echo and Atom, both fell foul of potential trademark conflicts, so the group invited nominations for a new set of names and a vote began. I myself entered a vote for one of the candidates, hoping to see a quick end to the naming process so that there could be some real progress in establishing the specification. FeedCast wasn't a wonderful name, but one of the things I've learnt about branding is that the actual name itself matters much less than the image you create around it. Provided the name has no negative connotations or practical obstacles, then it's much better to just get on with it and make it work.

It wasn't to be. I had a sinking feeling as the voting progressed, noticing that many of the original participants in earlier discussions weren't casting their votes in the naming poll. This suggested a) that the project itself was losing momentum and b) that there were a lot of people who disliked all of the suggested names. This turned out to be the case. A 'None of the above' option was added to the list of candidates and quickly amassed a plurality. No one paused to consider the effect on the (still nameless) brand.

So now it's back to square one, with the added absurdity of some participants actually spending energy on debating what the project's temporary name should be. At this rate, the most appropriate name for these idealists in search of the perfect solution should probably be "Betamax". Meanwhile, Dave Winer (until recently the main owner of the RSS 2.0 standard) has chimed in with allegations of back-channel discussions and less-than-open procedures.

It's a real shame to see the project's initial good intentions squandered in backbiting, but there may after all be a silver lining. I recall observing in the early 90s, when IBM engaged on a major restructuring process to climb back from its huge losses, that several of its less-than-sharp executives seemed to be winning transfers into its disk drive and printer manufacturing operations. A few months later, IBM announced plans to spin off those divisions as separate companies, neatly divesting itself of a tranche of dull-but-worthy managers without incurring huge redundancy costs.

The not-Echo, Atom, whatever-it's-called project looks set to fulfil a similar role today as a sink for deadwood, drawing off all the vitriol and dissent that's previously been focussed on the existing RSS specification, which with any luck will be left free to flourish as a result.
posted by Phil Wainewright 7:21 AM (GMT) | comments | link