I’m no longer calling feeds “RSS feeds”. From now on I’m calling them “syndication” feeds, or just “feeds”. There have been two standards for doing this type of XML-based website syndication for a long time now — Atom and RSS. RSS is older and has more penetration, so its name has been confused with its function. Just like Xerox, Kleenex and Google.

Well, I don’t use Xerox to mean copy, I don’t use Kleenex to mean tissue, and the only reason I use “google” to mean search is because it’s vastly superior to the alternatives. If that changes I’ll drop it as well.

And that’s the case with RSS. It’s not simply not superior to Atom — it’s inferior. Here are a few of the highlights:

1. Atom offers a number of technical advantages that hinge on a more precise and scalable definition. Think XHTML vs. HTML4. Examples include (from the Atom Wiki):
   • RSS 2.0 requires feed-level title, link, and description. RSS 2.0 does not require that any of the fields of individual items in a feed be present. Atom 1.0 requires that both feeds and entries include a title (which may be empty), a unique identifier, and a last-updated timestamp.
   • RSS 2.0 may contain either plain text or escaped HTML, with no way to indicate which of the two is provided, and the RSS 2.0 content model does not permit actual well-formed XML markup, which reduces the re-usability of content. Atom has a carefully-designed payload container, where content must be explicitly labeled.
   • RSS autodiscovery has been implemented several times in different ways, often relies on unregistered (thus invalid) application/rss+xml MIME type, and has never been standardized. Atom [WWW]standardizes autodiscovery. The application/atom+xml MIME Type is registered with IANA. Additionally, Atom feeds contain a “self” pointer, so a newsreader can auto-subscribe given only the contents of the feed, based on Web-standard dispatching techniques.
   • RSS 2.0 is not in an XML namespace but may contain elements from other XML namespaces. There is no central place where one can find out about many popular extensions. Atom 1.0 is an XML namespace and may contain elements or attributes from other XML namespaces.
   • RSS 2.0 does not specify the handling of relative URI references. Different feed readers implement differing heuristics for their interpretation. There is no interoperability. In practice, relative URI references cannot be used in RSS feeds.Atom 1.0 specifies use of the XML’s built-in xml:base attribute for allowing the use of relative references.
   • RSS 2.0 can be encrypted or signed like any other web content, if treated as arbitrary content. Rules for applying standard XML Encryption and XML Digital Signature on entries are included in Atom 1.0.
   • The RSS 2.0 specification includes no schema. Atom 1.0 includes a (non-normative) ISO-Standard RelaxNG schema, to support those who want to check the validity of data advertised as Atom 1.0.
2. Atom is run by the Atompub Working Group group is specified in RFC 4287 while RSS is basically run by a single genius who’s arguably very hard to work with.

   “Dave Winer has done a tremendous amount of work on RSS and invented important parts of it and deserves a huge amount of credit for getting us as far as we have. However, just looking around, I observe that there are many people and organizations who seem unable to maintain a good working relationship with Dave.” — Tim Bray (member of the W3C and co-creator of XML)

3. Google perfers Atom.

   “That is the sound of inevitability.”

The bottom line for me is that Atom seems to be more technically sound as well as more open. When you combine that with Google having chosen it as their preferred syndication protocol, that pretty much seals it for me.

I’m not going to be calling feeds “Atom feeds” — that would be lame — but I am going to dump the RSS bit. In my view Atom is clearly the winner long-term.:

I recently wrote a piece about why we need to abandon the use of “www” both in speech and in technical implementation. The overwhelming response led me to wonder how the business world was handling the issue. How do the “serious” companies deal with requests that don’t include the “www” prefix?

I started with the 2007 Fortune 500 list and sampled the first 50 (the Fortune 50) by querying them without the www prefix, i.e. by domain.tld rather than www.domain.tld. Here are the results.

• 30 out of 50 (60%) redirected to the www version of the site. [Bad]
• 17 out of 50 (34%) accepted the requests as-is. [Best]
• 3 out of 50 (6%) failed completely. [Worst]

These results show that the business world understands that accessing sites without the “www” prefix should be supported, with only 6% failing to handle the requests. Most companies either answered as requested or redirected to the www-version. This further supports my claim that users should drop the practice of using “www” when typing URLs on their computer and when communicating website addresses to others.

Using “www” is simply not necessary for the vast majority of web sites. Typing it is a waste of time, printing it wastes ink and materials, and pronouncing it alone takes longer than saying most website domains themselves (9 syllables for three characters?). Just stop using it.

Of course, the ideal situation is the opposite — where the “www” requests are redirected to the non-www URL. This helps with SEO, caching, certificate domain issues, and gives users a single convention to remember.

That’s the ideal, but I suppose we have to take small steps.:

– Here are the companies that were compliant:

daniel@hermes ~ $ cat fortune | grep ^y y exxonmobil y chevron y berkshirehathaway y merrill lynch y altria y kroger.com y boeing y marathon y wellpoint y searsholdings y pfizer y dow y united technologies y ups y wachovia y lehman y fredditmac

And here are the companies that failed:

daniel@hermes ~ $ cat fortune | grep ^f f mckesson f amerisourcebergen f metlife

—-

<

p class=”entrybody”>Orange DoD Trusted Computer System Evaluation Criteria

Green DoD Password Management Guideline

Tan A Guide to Understanding Audit in Trusted Systems

Bright Blue Trusted Product Evaluations – A Guide for Vendors

Neon Orange A Guide to Understanding Discretionary Access Control in Trusted Systems

Teal Green Glossary of Computer Security Terms

Red Trusted Network Interpretation of the TCSEC (TNI)

Amber A Guide to Understanding Configuration Management in Trusted Systems

Burgundy Book A Guide to Understanding Design Documentation in Trusted Systems, 6 October 1988. () see also Process Guidelines for Design Documentation which may supercede parts of this document.

Dark Lavender Book A Guide to Understanding Trusted Distribution in Trusted Systems 15 December 1988.

Venice Blue Book Computer Security Subsystem Interpretation of the TCSEC 16 September 1988. ()

Aqua Book A Guide to Understanding Security Modeling in Trusted Systems, October 1992.

Red Book Trusted Network Interpretation Environments Guideline – Guidance for Applying the TNI, 1 August 1990.

Pink Book RAMP Program Document, 1 March 1995, Version 2

Purple Book Guidelines for Formal Verification Systems, 1 April 1989

Brown Book A Guide to Understanding Trusted Facility Management, 18 October 1989

Yellow-Green Book Guidelines for Writing Trusted Facility Manuals, October 1992.

Light Blue Book A Guide to Understanding Identification and Authentication in Trusted Systems, September 1991.

Light Blue Book A Guide to Understanding Object Reuse in Trusted Systems, July 1992.

Blue Book Trusted Product Evaluation Questionaire, 2 May 1992, Version 2.

Silver Book Trusted UNIX Working Group (TRUSIX) Rationale for Selecting Access Control List Features for the UNIX® System, 7 July 1989.

Purple Book Trusted Database Management System Interpretation of the TCSEC (TDI), April 1991.

Yellow Book A Guide to Understanding Trusted Recovery in Trusted Systems, 30 December 1991.

Bright Orange Book A Guide to Understanding Security Testing and Test Documentation in Trusted Systems

Purple Book A Guide to Procurement of Trusted Systems: An Introduction to Procurement Initiators on Computer Security Requirements, December 1992.

Purple Book A Guide to Procurement of Trusted Systems: Language for RFP Specifications and Statements of Work – An Aid to Procurement Initiators, 30 June 1993.

Purple Book A Guide to Procurement of Trusted Systems: Computer Security Contract Data Requirements List and Data Item Description Tutorial, 28 February 1994. ()

Purple Book A Guide to Procurement of Trusted Systems: How to Evaluate a Bidder’s Proposal Document – An Aid to Procurement Initiators and Contractors

Forest Green Book A Guide to Understanding Data Remanence in Automated Information Systems, September 1991, Version 2, (Supercedes CSC-STD-005-85).

Hot Peach Book A Guide to Writing the Security Features User’s Guide for Trusted Systems, September 1991. ()

Turquoise Book A Guide to Understanding Information System Security Officer Responsibilities for Automated Information Systems, May 1992.

Violet Book Assessing Controlled Access Protection, 25 May 1992.

Blue Book Introduction to Certification and Accreditation Concepts, January 1994.

Light Pink Book A Guide to Understanding Covert Channel Analysis of Trusted Systems, November 1993.

The reason for using the “www” hostname prefix when entering websites is now a matter of history. It’s old. Deprecated. Outdated. Antiquated. Like websites that only work in Internet Explorer, sites that break when you use the domain alone should be firmly encouraged to join the 21st century. It’s wasteful to type, and it’s cumbersome to pronounce. Consider that it takes nine syllables to properly enunciate three characters. Some argue that there is still a good reason to separate traffic destined to web servers from that destined to the domain itself. I think this is precisely the idea that’s become obsolete. The reason for that differentiation in the past was that the other protocols were as prolific (or even more prolific) than HTTP at the time. HTTP was just one of many, so it made no sense at the time to give any type of traffic a preference by pointing the root of a given domain to the system that hosted that content. Things are different now. HTTP is utterly dominant. Any site interacting with the public on any serious scale does so via a web server, so making this the default is a matter of obvious practicality. This doesn’t mean we should abolish the use of hostnames. Hostnames are excellent tools for separating traffic and making meaningful associations with users. The argument here is simply for having the root point to the web content.

Compatibility

There are four basic levels of no-www compatibility:

1. Your site is available via www.domain.tld only. If you use the domain alone your request will fail.
2. Your site is available via both www.domain.tld and domain.tld, but www.domain.tld does not redirect to domain.tld.
3. Your site is available via both www.domain.tld and domain.tld, and www.domain.tld does redirect to domain.tld.
4. Your site is available only via domain.tld and www.domain.tld will break.

I personally recommend webmasters implement #3, and don’t advise #4 for any reason. The discussion here is about improving usability through simplification, not breaking things for the satisfaction of being pedantic.:

No-www is an initiative to make all websites accessible from both the http://www.example.com/ and http://example.com/ forms of their names. The reason behind it is to standardize domain names providing web content and to avoid typing unnecessary letters. — Wikipedia

The reason for using the “www” hostname prefix when entering websites is now a matter of history. It’s old. Deprecated. Outdated. Antiquated. Like websites that only work in Internet Explorer, sites that break when you use the domain alone should be firmly encouraged to join the 21st century. It’s wasteful to type, and it’s cumbersome to pronounce. Consider that it takes nine syllables to properly enunciate three characters.

Some argue that there is still a good reason to separate traffic destined to web servers from that destined to the domain itself. I think this is precisely the idea that’s become obsolete. The reason for that differentiation in the past was that the other protocols were as prolific (or even more prolific) than HTTP at the time. HTTP was just one of many options, so it made no sense to give any type of traffic a preference by pointing the root of a given domain to the system that hosted that content.

Things are different now. HTTP is utterly dominant. Sites interacting with the public on any serious scale does so via a web server, so making this the default is a matter of obvious practicality. This doesn’t mean we should abolish the use of hostnames. Hostnames are excellent tools for separating traffic and making meaningful associations with users. The argument here is simply for having the root point to the web content as a matter of convention.

As for people who include it when speaking, there’s no need to be rude when correcting them. Just kindly inform them that it’s faster if they just go to the domain itself, and that the “www” isn’t needed.

For more information, check out the no-www FAQ, and feel free to fly their sitecon seen above.:

[Edited 07.27.07]

p style=”text-align: center”> howstufworks.com

We all hear the term “web 2.0″ being used hundreds of times a week. It’s all over the Internet and it pervades modern technical conversation to the point of being cliché. But what does “2.0″ really mean? What came before it? And what’s coming next? Here are some basics.

Web 1.0 This is the first iteration. It wasn’t actually called web 1.0, of course; it was just “the web”, or “the Internet”. You don’t call something version 1 when you aren’t anticipating a second version. This version was (and still is)…

A system of interlinked, hypertext documents accessed via the Internet. With a Web browser, a user views Web pages that may contain text, images, and other multimedia and navigates between them using hyperlinks.

Web 2.0 Interestingly enough, Web 2.0 doesn’t truly correspond to a change in technology. While AJAX is commonly associated with Web 2.0 functionality, the difference is actually in how web 2.0 applications are used, not in how they are implemented. Web 2.0 is…

A perceived second generation of web-based communities and hosted services — such as social-networking sites, wikis and folksonomies — which facilitate collaboration and sharing between users.

Web 3.0 This is the current holy grail — the semantic web. The semantic web represents a shift from documents to data, meaning that data will be presented to humans and computers alike that can be manipulated in various ways. Most importantly, however, there will be meaningful links connecting these various sets of data.

The semantic web is an evolving extension of the World Wide Web in which web content can be expressed not only in natural language, but also in a form that can be read and used by software agents, thus permitting them to find, share and integrate information more easily.^[1] It derives from W3C director Sir Tim Berners-Lee‘s vision of the Web as a universal medium for data, information, and knowledge exchange.

In other words, the semantic web links information together in a way that is both useful and automatic rather than manual and disjointed. It’s a collection of data resources that are interconnected and speak the same language.

Using the semantic web will be similar to asking a personal assistant to help you accomplish something. You might say, “Find me all bilingual Porsche dealers within 200 miles that are open on Sunday, and add their sales staff contact information to my address book. Also, let me know if any of their employees have published contacts within 2 degrees of separation from me.”

This will be possible because all that information (business type, language proficiencies, location, contact information, etc.) will be available through the company’s Internet presence. And most importantly, this information will be easily processed and manipulated by any semantically-aware software agent. That’s web 3.0..:

– Quoted text is from Wikipedia