Professor von Clueless in the Blunder Dome

Retiring InfoNuovo.com

noreply@blogger.com (orcmid) — Wed, 31 Dec 2008 16:44:00 +0000

Technorati Tags: infonuovo.com, InfoNuovo, ODMA, nfoCentrale.com

[cross-posted 2008-12-29T16:42Z from Orcmid’s Lair. Some of the oldest links that still use the infonuovo.com domain are related to ODMA. This post is here to catch those who might end up searching for previously-found ODMA material and wonder where it has gotten too.]

I am retiring the InfoNuovo.com domain after 10 years. The domain will be cast loose at the beginning of February, 2009. Those places where there are still references to infonuovo.com need to be updated:

infonuovo.com, my original “anchor site” for several topical web sites, is now replaced by nfoCentrale.com. From now on there is no reason to refer to either infoNuovo.com or nfoCentrale.com (or its partner, nfoCentrale.net). The topical web sites have their own domain names. Those domain names should be used in bookmarks everywhere.
infonuovo.com/odma will continue to be found at ODMA.info
infonuovo.com/dma will continue to be found at DMAtech.info
infonuovo.com/orcmid will continue to be found at orcmid.com
infonuovo.com/dmware will continue to be found at DMware.info

and so forth for any other infonuovo.com links that may be tucked-away somewhere.

If you have an infonuovo.com bookmark and you are not sure of its replacement, simply use it and notice the URL of the destination that appears in the address bar of your browser. That is the URL that should be bookmarked.

InfoNuovo.com was the first domain name that I ever rented. It was originally hosted on VServers and absorbed through acquisitions a couple of times. On March 22, 1999, I posted my first construction note on the use of InfoNuovo.com as an anchor site, a web site that houses other web sites as part of a single hosting. This was also the first step toward evolution of what I now call the construction structure of any nfoCentrale web site. InfoNuovo was the company name I had chosen for my independent consulting practice initiated on retirement from Xerox Corporation in December, 1998.

When I moved from Silicon Valley to the Seattle Area in August, 1999, I found that InfoNuovo was too easily confused with a name already registered in Washington State. The business became NuovoDoc, but I continued to hold the infonuovo.com domain name for the support of the subwebs housed there. I eventually moved most content to the new anchor, nfoCentrale.net, on Microsoft bCentral.

There was one problem. Although I could redirect unique domain names, such as ODMA.info, to the current anchor, the web pages still served up with the URLs of the actual location on the anchor site. I experimented with URL cloaking, but that created as many problems as it solved.

In October 2006, following the lead of Ed Bott, I switched to A2 Hosting as a way to reduce the hosting fees and also take advantage of the A2 shared hosting Apache-server provisions for addon domains. Addon domains serve up with URLs of their domain even though the domain is anchored on a single hosted site (in this case, nfoCentrale.com). I consolidated all nfoCentrale.net and infonuovo.com content on nfoCentrale.com. I also parked domains nfoCentrale.net and infonuovo.com where they are today, atop nfoCentrale.com. Now, however, accessing any of the individual subwebs triggers redirection to the appropriate addon-domain URL.

This took care of my wanting to have the subwebs always respond as the domains that I have as their addons. It also raised an unexpected problem around case-sensitivity of Apache filenames, a situation I am still digging my way out of. That shows how important having the addon-domain capability is to me. I’m not sure I’d have moved if I knew how difficult the case-sensitivity extrication would be though.

I know that there are still infonuovo.com URLs out there, even though the addon domains have been in place for over two years. In another month, those URLs will fail. I just don’t want to lease infonuovo.com any longer. I do feel a little sentimental about it. That’s not going to stop me.

Confirmable Experience: What a Wideness Gains

noreply@blogger.com (orcmid) — Tue, 07 Oct 2008 23:16:00 +0000

Technorati Tags: confirmable experience, successful communication, dependable systems, usability, cybersmith

[Here’s another confirmable experience cross-posting. There’s some food for thought here for having displays that support your own productivity and enjoyment of sessions at the computer. There’s also something to be cautious about when assuming things about the ways users experience the interfaces that you implement. I know that I often design interfaces for myself, and that may be far short of what is workable for another who doesn’t approach their work in the same way and who doesn’t have the same computer setup.]

Four years ago, I replaced a failing 21” CRT display with a 20” LCD monitor. The improvement was amazing. I have since upgraded my Media Center PC with a graphics card that provided DVI output and there was more improvement.

But the greatest improvement came when the 20” LCD monitor recently began to have morning sickness, flickering on and off for longer and longer times before providing a steady display. Before it failed completely, I began shopping for the best upgrade on the competitive part of the LCD monitor bang-for-buck curve.

These days, 24” widescreen LCD monitors are the bees knees. For almost half what I paid for the 20” LCD in 2004, I obtained a 1920 by 1080 DVI LCD (Dell S2409W) that is not quite the the same 11.75” height but is 21” wide. The visual difference is dramatic when viewing 16:9 format video and also when viewing my now-favorite screensaver. I added a shortcut to my Quick Start toolbar just to be able to watch the screensaver and listen to the bubbles while making notes at my desk.

One of the problems I had with the 20” old-profile (6:4, basically) was that I could not work with multiple documents open at the same time. I don’t mind only having one fully on top, but I often needed to be able to switch between them easily. In some standards-development work that requires comparison of passages in different documents, it was also tricky to have them open in a way where I could line up the material to be compared and checked.

The wider display permits having more of an application open, such as Outlook, and it also allows access to additional open material.

What I hadn’t expected was the tremendous improvement that becomes available when there is a 21” task bar at the bottom of the screen. I did not expect an advantage there as the result of the wider display. That alone has made my working at the computer more enjoyable and more fluid.

My desktop is still too cluttered with icons and I am still tidying them up, removing ones that I rarely use. Even so, the perimeter of the display provides for more icons on the outside of the central work area so that I can find them without having to close or move application windows. That’s another bonus.

I must confess that I haven’t had so much fun since I progressed from Hercules-graphics amber monitors to full-color displays in the early 90s. It is sometimes difficult to realize that it wasn’t that long ago.

Oh Yes, the Confirmable Experience …

There are two confirmable-experience lessons here. First, the subjective experience I am having is mine. The wide-format monitor is an affordance for my heightened excitement and enjoyment, but the experience is mine. Others have different reactions and, in particular, have their own ideas about display real-estate, task bars, and other user-interface provisions.

For the second lesson, recall how much emphasis I give to using a screen-capture utility for computer forensic and trouble-reporting work. That will often provide important out-of-band evidence for a problem that one user is seeing and that another party does not.

These screen captures provide similar evidence of what the wider-format display provides for me.

They don’t provide any assurance that you will see them the same way I do, however. If you click through to the full-size images, you’ll see a rendition of the same bits that my display shows me. I assure you that the image I see when replaying those bits to my screen is exactly the same as the one I took a screen capture of.

There are a number of ways that your experience will be different. At the most fundamental level, there is no way to know, using these images only, to determine whether the color presented for a particular pixel on your display is the same that I see on mine. The PNG files do not reflect what I saw. They do faithfully reflect what my software and graphics card used in the internal image that was presented via my display. But we have no idea whether your computer is presenting the same color using the same bits. There are other differences of course, in that gross features may not be viewable in the same way my monitor allows me to see them (unless yours has at least the 1920 by 1080 resolution that mine does). This is all there to interfere with our sharing this particular experience of mine even without allowance for our different vision and subjectivity influences.

The takeaway for this part is that context matters with regard to what qualifies as a confirmable and confirmed experience. It’s also useful to notice how many different aspects of the computer bits to displayed pixels pipeline can influence whether or not I have successfully shared relevant aspects of my experience with you.

And we do manage to make it all work, most of the time, for most of us.

Confirmable Experience: Consider the Real World

noreply@blogger.com (orcmid) — Sun, 05 Oct 2008 22:16:00 +0000

Technorati Tags: Clarke Ching, confirmable experience, successful communication, dependable systems, trustworthiness, cycle of learning and improvement, usability

[cross-posted from Orcmid’s Lair, essentially for the reasons stated here.]

Clarke Ching just posted a great illustration of a confirmable-experience situation. Until a set of comparative photographs was available to illustrate some different experiences, he and his wife did not know how to understand a difficulty that one had and the other did not (and check the follow-up for more important reality).

This is the entire crux of it.

I often go on about the importance of confirmable experience in the area of trustworthy and dependable systems. Providing confirmable experience is something software producers (and motivated power users) need to pay attention to. Clarke provides the Cool Hand Luke reality version. Sometimes communication is not simple and it is important to remove the barriers.

I posted this on Orcmid’s Lair and I also wanted to drag it into my confirmable-experience cybersmith collection too. I want it there because it is so juicy, even though this is not my main confirmable-experience category location. Well, I think not. I will resolve it for now with cross-posting. Sometimes, I need to make a mess to know that is not the way to do it. Now I have to dig my way out of it.

Cybersmith: IE 8.0 Mitigation #1: Site-wide Compatibility

noreply@blogger.com (orcmid) — Sat, 13 Sep 2008 06:49:00 +0000

Technorati Tags: cybersmith, interoperability, IE8.0 mitigation, web site construction, web standards, compatibility

I have been experimenting with Internet Explorer 8.0 beta 2 enough to realize that all of my own web sites are best viewed in compatibility mode, not standards mode. I find it interesting that other browsers, such as Google Chrome, apparently apply that approach automatically, suggesting to me that the IE 8.0 standards mode is going to cause tremors across the web.

The first step to obtaining immediate, successful viewing under IE 8.0, as well as older and different browsers, is to simply mark all of my sites as requiring compatibility mode. That is the least activity that can possibly work. It provides a tremendous breathing room for being more selective, followed eventually by substitution of fully-standard versions of new and heavily-visited web pages on my sites.

Some pages may remain perpetually under compatibility mode, especially since the convergence of web browsers around HTML 5 support will apparently preserve accommodations for legacy pages designed against non-standard browser behaviors.

This post narrates my effort to accomplish site-wide selection of compatibility mode by making simple changes to web-server parameters, not touching any of the web pages at all.

#0. The Story So Far
#1. The Simplest First Step That Can Possibly Work
2. Satisfying the Prerequisites
3. Experimental Approach for Confirming mod_headers Operation
4. Web Deployment Approach
5. Authoring the .htaccess File
6. Deploying the .htaccess File
7. Confirming .htaccess Success
8. Shampoo, Rinse, Repeat
9. Tools and Resources

See also:
2008-08-30 Orcmid's Lair: Interoperability: The IE 8.0 Disruption for the situation and the basic approach
[undated] MSDN Library: Defining Document Compatibility, Internet Explorer 8.0 beta, preliminary
[undated] MSDN Library: Implementing the META Switch on Apache, preliminary
2008-08-28 Hanu Kommalapati: Apache httpd configuration for IE7 standard mode rendering in IE8 (via Bruce Kyle)

#0. The Story So Far

On installing Internet Explorer 8.0 beta 2, I confirmed that none of my web sites render properly using the default standards-mode rendering. However, my sites render as designed for the past nine years if I view them in compatibility mode.

Although I want to move my high-usage pages to standards-mode over time, I don't want users of Internet 8.0 to have to manually-select compatibility mode when visiting my sites and their blog pages.

What I want now is the simplest step that will advertise to browsers that my pages are all to be viewed in compatibility mode. This will direct the same presentation in IE8.0 as provided by older versions of Internet Explorer and and current browsers (such as Google Chrome) that don't have the IE8.0 standards mode. I can then look at a gradual migration toward having new and high-activity pages be designed for standards-mode viewing while other pages may continue to require compatibility mode indefinitely.

#1. The Simplest First Step That Can Possibly Work

There are ways to have web sites define the required document compatibility without having to touch the existing web pages at all. If I am able to accomplish that, I will have achieved an easy first step:

Have a complete site automatically set to be browsed in compatibility mode (EmulateIE7, in my case), buying time to provide finer grain solutions.

This is accomplished by convincing the web server for my sites to insert the following custom-header line in the headers of every HTTP response that the server makes:

X-UA-Compatible: IE=EmulateIE7

The HTTP-response lines precede the web page that the web server returns. The browser recognizes all lines before the first empty line as headers. Everything following that empty line is the source for the web page. The browser processes the headers it is designed to recognize and ignores any others.

You can see the headers returned as part of an HTTP request by using utilities such as cURL and WFetch. Here are the headers from my primary web site using a show-headers-only request via the command-line tool, cURL:

2. Satisfying the Prerequisites

The MSDN Article on Defining Document Compatibility describes site-wide compatibility control for two web servers: Microsoft Internet Information Server (IIS) and Apache HTTP Server 1.3, 2.0, and 2.2.

Have direct access to the folders of web pages on my web server.
Satisfied: I have FTP access to the complete set of directories that hold web pages for my sites.
Determine that my Apache web server is one of those discussed.
Satisfied: My web-site hosting service uses Apache HTTP Server on Linux. When I check the administrator control panel provided by the hosting service, I discover that I am on Linux kernel 2.6.9 and Apache version 2.2.9 (Unix). The Apache 2.2 requirement is satisfied.
Determine that I can set server-level response.
Not Satisfied: My sites (nfoCentrale.com and all domains that are added-on and shared under it) are on a shared server. I do not have access to the overall server nor to the httpd.conf configuration file.

The Apache 2.2 Module mod_headers documentation and Hanu Kommalapati's example describe how directory-level response headers can be specified instead.

Determine that I can set directory-level response headers.
Not Clear: I know that I can create .htaccess files everywhere on my sites. I don't know whether mod_headers is installed in my server configuration. This list suggests that the option is not available, and there might not even be dynamic loading of extensions (mod_so). The easiest way to confirm the actual state of affairs is by experiment.

To Be Verified: I also submitted a support ticket; the hosting company responded immediately. The answer is, yes, mod_headers is supported on my server. Great! Now to see it working.

3. Experimental Approach for Confirming mod_headers Operation

I want to introduce an .htaccess file that has the following content:

<IfModule headers_module>
Header set X-UA-Compatible: IE=EmulateIE7
</IfModule>
I will try it out on a site that is a placeholder with no meaningful content and no visitors other than myself: eoware.org.
The current state of the site has the following default result when I direct IE8.0 beta2 to http://eoware.org:


This portion of the default page is shown in default standards-mode view. Notice the broken-page button to the left of the refresh button. This indicates that a compatibility-mode view is available.

This rendering is not in agreement with how the page was designed (and not touched since 2006). Notice the color of the horizontal line, and the (added) spacing in the right-justified revision-history information lines.
When compatibility view is selected, the page appears as it was designed (non-standard as it is):



The compatibility button is depressed, the horizontal line is the proper deep-blue color, and the spacing of the right-justified revision-history information is as expected.
The desired state is as in (4) but with no action needed from the user and with the compatibility-view button not presented. This will confirm that, for this site, the EmulateIE7 mode has been specified and automatically honored by the browser. Other browsers (such as the initial Google Chrome release and older versions of Internet Explorer) will default to this view regardless; the custom HTTP header is harmlessly ignored by older browsers.

4. Web Deployment Approach

Having direct FTP access to the web-page folders on my server, along with an out-of-the-way place to try out the change, is relatively safe. Since I am placing an .htaccess file where there presently is none, it is feasible to (1) upload the file, (2) see if it works, and (3) quickly delete it if there is any failure. Having succeeded in introducing .htaccess files for other purposes, I'm confident I can make the change correctly.

I'll not do it that way. Instead, I will rely on my web-deployment-safety model and take advantage of the safety net it affords, even though I could do without it if all I wanted was experimental confirmation. This is a cybersmith post, and I want to illustrate a disciplined approach that has more flexibility in the long run. To see the result that could have been attained by using the direct approach, you can peek ahead to section 6, below, and the image just above it.

Here is the structure of safeguards that I employ to control updates to my sites, keep them backed up, and also have a way to restore/move some or all of the sites. I can also roll-back changes that are incorrect or damaging. I can repair a corrupted site too (and I have had to do that in the past).

The hosted-site web-server pages are maintained using FTP between the server and a private development server which holds a complete image of the hosted-site content. This mirror is in the file system of the development server (an old lap-top running Windows XP and connected on my household LAN for duty as a light-weight server). Synchronization between the site and the mirror is accomplished by FTP in either direction, depending on where new content first appears (on the server for Blogger web logs, on the development server for manually-authored pages and their updates).

**Basic Site Deployment Setup.** The hosted-site is kept synchronized by FTP with a file-system image (left) on a private development server. The content of **http://nfocentrale.com** is mapped to the folder structure starting at **public_html**. The Visual Source Safe project **$/A2HostingWeb** provides source-code management, versioning, and backup of the **public_html** image (right).

In addition to being separately backed-up, the hosted-site image corresponding to http://nfocentrale.com is also the working folder of a Visual SourceSafe project, $/A2HostingWeb. VSS holds the current and also older versions of site material. VSS is also the source of newly-authored material that is ready to be added to the image and published to the hosted-site itself.
At the web-site, the eoware folder under public_html (the http://nfocentrale.com top level) has also been defined as the top level of the eoware.org domain. This is accomplished by use of the hosting-service administrative control panel to create an add-on domain (of an already-leased domain name) at a particular sub-folder of my main site. This feature is a key factor in my choice of the particular hosting service.   In addition, the .htaccess file that I already have in public_html causes any access directly to the eoware/ folder to be redirected to use the http://eoware.org URL. This forces the correct address in the browser for use in book-marking and in search results. These two cURL requests demonstrate the mapping:
To use this deployment path, I need to author the desired .htaccess file and have it checked-into VSS under the $/A2HostingWeb/eoware/ project. To deploy the new material, the content is exported (using Get Latest Version ...) to the file-system site-image location on the development server computer: c:\publicca\A2hosting\public_html\eoware\. Transfer to the web site is by FTP synchronization of the site-image eoware\ folder and the corresponding hosted-site folder.
Although this is a roundabout way to make this individual page, it maintains the practice of not ever authoring directly in the deployment path except under serious emergency. In the absence of an emergency, all development-site authoring occurs elsewhere and is brought under VSS management first. New and changed material flows from VSS to the site image to the web site.

Some new material and changes do originate on the hosted site first. Typical site-first materials include blog posts originated from Blogger and Windows Live Writer, wiki pages (whenever that day comes), and data gathered from web-page forms. Those materials are also periodically synchronized from the hosted-site to the site image and then checked into VSS, keeping a complete site image on the development server under VSS management and for backup.

5. Authoring the .htaccess File

If I was simply making an .htaccess page, I would create it directly in a text editor, having a file such as that created in step 4, below. That page would be saved at a convenient location-machine address and then transferred to the hosted-site using FTP, leading to the result in section 6.

To preserve my development and deployment model, I require more steps.

Although I also have a development web site on the development server, it is an IIS server, not an Apache HTTP Server. The IIS server, FrontPage 2003, and the FrontPage Server Extensions that I use to perform web-page authoring do not permit editing of Apache .htaccess pages and their automatic inclusion under source-code management.

I cling to this web-page authoring model not merely because I have used it since 1998, although that's reason enough. I place high value on the development web-site pages being kept under automatic source-code management using Visual Source Safe. I use the sharing feature of VSS to share the development-site web page content into the $/A2HostingWeb project too. This permits staged synchronization between the development site, the hosted-site image, and indirectly the hosted site itself; and, vice versa. (For those wondering what's on the quiz, I call this a hybrid Microsoft Site Server model, because it works in both directions to also capture authored material that arises initially on the hosted site.)

Because .htaccess files and other Apache-site administration files need to be introduced under source-code management some other way than via FrontPage and my development web site, there's an administrative skeleton project, $/A2HostingAccount, that mimics the folder structure of the hosted-site image just enough to carry any administrative files.

**Working Project for Authoring Adminstrative Files**. Project **$/A2HostingAccount** holds administrative pages that are shared to the hosted-site via **$/A2HostingWeb** (left). Working folders under the local **c:\MyProjects\A2HostingAccount** directory provide check-out and editing of the **.htaccess** file (right).

The $/A2HostingWeb folder structure is replicated in $/A2HostingAccount only to the levels where .htaccess files appear. The same .htaccess file is shared between a folder of $/A2HostingAccount and the same folder of $/A2HostingWeb. In this way, $/A2HostingWeb has source-code management of the entire hosted-site image and $/A2HostingAccount provides a view that is limited to the administrative material.

Because I already have some .htaccess pages for my server, I have lifted an existing one (from nfoworks) by sharing it to eoware, branching it so that changes don't reflect back to nfoworks, and sharing the newly-branched one to $/A2HostingWeb/eoware/ (so that changes will also be seen in that project). This pattern will be re-used to quickly make more .htaccess pages for the root folders of my remaining web sites that need one as part of IE8.0 mitigation.
The customization of the new .htaccess file is accomplished by performing a VSS Get Latest Version ... operation of the eoware project to the working folders on my local machine (on the right, above).

The next step is to open the local .htaccess copy in a VSS-aware editor and check out the file (or check it out first otherwise). The checked-out version is edited to customize it for the new destination, adding the IE8.0-mitigating mod_headers instructions.

After editing is complete, the changed file is saved to disk and checked-in via VSS control.

This is the completed result:

6. Deploying the .htaccess File

Having edited the .htaccess file on my development machine and checked it into VSS (on the development server), the next steps are all conducted on the development server:

Using VSS on the development server, I perform a Get Latest Version ... operation on the $/A2HostingWeb/eoware project. This delivers the newly-customized .htaccess file to the hosted-site image, the working folders for $/A2HostingWeb there.
Using WS_FTP Pro on the development server, I connect to the hosted site.
After connection, I drag the hosted-site image c:\publicca\A2Hosting\public_html\eoware\ folder to the connected-site /public_html folder in the WS_FTP connecting- and connected-site panes. The eoware/ folder of the connected site is updated with any new or more-recent files from the hosted-site image. I see that the .htaccess file is now there.

This is the same deployment procedure for updating of any of my individual sites under the hosted-site. A script for it would be useful. This is on my someday-not-now list. Scripted or not, this is the basic procedure.

7. Confirming .htaccess Success

Assuming that the .htaccess introduction has not derailed the server, confirmation of the parameters and their success is straightforward:

Access to eoware.org with the cURL utility should reveal the custom header in the response. There it is:
Next, access to http://eoware.org/ with IE 8.0 beta 2 should provide a different experience. And here that is:

This access automatically provides the compatibility view and there is no Compatibility View button. (Compare with the second result in section 3.)

8. Shampoo, Rinse, Repeat

We've demonstrated that the .htaccess customization works correctly on my web site and provides the desired result on a little-used URL that is a placeholder for work yet to come. After this cautious effort, it will be straightforward to add similar .htaccess files to each of the individual sites implemented on the hosted-site.

Before that, I will first add the custom-header response to the .htaccess file that is already at public_html, the root of the main site, http://nfocentrale.com. This provides the custom header for all access.

Once all site access returns the custom HTTP header, I can then take my time determining how to work toward migrating sections of web sites to pages that view properly in IE 8.0 standards mode. That will be accounted for as additional mitigation steps.

9. Tools and Resources

The following tools were used in this mitigation step:

cmd.exe, the Microsoft Windows XP command-line console shell
Hypersnap 6, for screen-shot diary and demonstration of the mitigation step
cURL 7.15.4, command-line HTTP request and response capture tool
Apache HTTP Server 2.2.9 (Unix), running as a shared server on a Linux web-hosting system
Windows XP computer for desktop development-site authoring
Windows XP computer providing the development web server (IIS), a co-located source-control database, and the hosted-site image for FTP synchronization with the hosting-service site
Visual SourceSafe 6.0d database on the same computer as the development web server
WS_FTP to synchronize directories without transferring unchanged material
jEdit 4.3 for editing the .htaccess page. Any basic text editor can be used. I use jEdit because (1) I already use it for other things, (2) it integrates with Visual Source Safe, and (3) it provides syntax highlighting for .htaccess files.

DMware: OK, What's CMIS Exactly?

noreply@blogger.com (orcmid) — Thu, 11 Sep 2008 00:26:00 +0000

Technorati Tags: DMware, IBM, Microsoft, CMIS, Content Management, iECM, EMC, Lotus, Sharepoint, Filenet, Open Text, OASIS, Web Services, interoperability, Document Management

There's a nice flurry of interoperability news today, announcing the Content Management Interoperability Services (CMIS) Specification sponsored by EMC, IBM, and Microsoft, with the participation of other content-management vendors, including Open Text. [update: There is extensive coverage on Cover Pages. I recommend that as the comprehensive source.]

Content/Document-Management Integration/Middleware Scheme for This Century?

The stratospheric view from Josh Brodkin suggests that CMIS is a means for cross-over between different content-management regimes as well as bridging from content-aware applications to content-management systems.

The Sharepoint Team describes CMIS as an adapter and integration model for access from content-aware applications in a CMS-neutral way, relying on distributed services via SOAP, REST, and Atom protocols.

The 0.5 draft specification (2008-08-28 6.64MB Zip File download) provides a core data model for expression of managed repository entities, with loosely-coupled interface for application access to repositories via that model:

"The CMIS interface is designed to be layered on top of existing Content Management systems and their existing programmatic interfaces. It is not intended to prescribe how specific features should be implemented within those CM systems, nor to exhaustively expose all of the CM system’s capabilities through the CMIS interfaces. Rather, it is intended to define a generic/universal set of capabilities provided by a CM system and a set of services for working with those capabilities."

It appears that a wide variety of service integrations are possible, although the basic diagram has the familiar shape of an adapter-supported integration on the model of ODBC (and TWAIN and ODMA). Although that's the model, the integration approach is decidedly this-century, relying on relatively-straightforward HTTP-carried protocols rather than client-side integration. Clients must rely on the Service-Oriented Interface, and there is room for provision of client-side adapters to encapsulate that. Either way, this strikes me as timely and very welcome.

Next Steps

The authors have been working for two years to arrive at the draft that will now be submitted to OASIS, estimating that it will take another year to finalize a 1.0 version. [Such a Committee Draft would then go through some rounds of review before promulgation as an OASIS Standard.]

I thought, at first, that this was some form of off-shoot from the AIIM Interoperable ECM (iECM) Standards Project, yet there is no hint of that in the CMIS materials nor on the iECM project and wiki pages.

Announcement of the Proposed TC has just appeared at OASIS [afternoon, September 10]. OASIS Members will make any comments on the proposed charter by September 24, after which there will be a call for participation and then an initial meeting. OASIS members who want to participate in the TC can sign up after the call for participation. The initial meeting is provisionally targeted for a November 10 teleconference. The first face-to-face meeting is planned for three days of mid-January in Redmond. You can follow the charter-discuss list here to see whether there are any questions about the charter, scope, and overlaps with other efforts.

Announcements, Commentary, and Resources

Josh Brodkin: EMC, IBM, Microsoft open up content management interoperability. Storage Knowledge Center, ComputerWorld, 2008-09-10
Larry Cannell: The Commoditization of Content Management? Collaboration and Content Strategies Blog, The Burton Group, 2008-09-10 (via William Vambenepe)
David Choy: Video: CMIS Technical Overview. 2 parts (via YouTube), EMC Labs, 2008-09-09
Robin Cover (ed.): Vendors Publish Content Management Interoperability Services (CMIS) Standard. News Item, Cover Pages, 2008-09-10
Ryan Duguid: Announcing the Content Management Interoperability Services. Microsoft Sharepoint Team Blog, msdn.com, 2008-09-09
David Ferris: CMIS Standard Announced. Ferris Research Blog, 2008-09-09 (via Rob Robinson)
Ethan Gur-esh: Announcing the Content Management Interoperability Services (CMIS) Specification. Microsoft Enterprise Content Management (ECM) Team Blog, msdn.com, 2008-09-09
Chuck Hollis: CMIS -- It's Not JAS. Chuck's Blog, 2008-09-10 (via PatriciaA)
Paul McDougall: Standards Deviant No More? Microsoft Embracing Protocols and Partnerships. InformationWeek, 2008-09-10
Mary McRae: Proposed Charter for OASIS Content Management Interoperability Services. Charter-Discuss List, OASIS Open, 2008-09-10
Gregory Melahn: Content Management Interoperability Services (CMIS). Lotus Quickr wiki, Lotus Software, 2008-09-10 (via IBM Lotus Tech Info)
Microsoft Corporation: EMC, IBM and Microsoft Jointly Create Web Services Interface Specification for Greater Interoperability of Enterprise Content Management Systems. PressPass, microsoft.com, 2008-09-10. Also EMC Newsroom Press Release, 2008-09-10; IBM Corporation Content Management Interoperability Services (CMIS) page (undated).
John Newton: Alfresco releases first CMIS implementation. Content Log, 2008-09-10 (via William Vambenepe)
Open Text Corporation: Open Text Pledges Support for New Content Management Interoperability Standard (CMIS), PR Newswire, 2008-09-10 (via Charged)
Craig Randall: CMIS - Content Management Interoperability Services. Craig's Musings, 2008-09-10 (via PatriciaA)
Craig Randall: Forrester's Kyle McNabb discusses Content Management Interoperability Services (CMIS). 14m30s podcast (MP3), undated.
Jignesh Shaw: Video: CMIS Application Scenarios. (6m11s via YouTube), EMC Labs, 2008-09-09
Jeff Teper: CMIS Specification (3m11s WMV video), Content Management Interoperability Services (CMIS) Virtual Pressroom, PressPass, microsoft.com, 2008-09-10
William Vambenepe: CMIS, APP, Zen-SOAP and WS-KitchenSink: some data points. William Vambenepe's blog: IT management in a changing IT world, 2008-09-11

[update 2008-09-12T08:09Z I am having trouble getting Blogger to push updates through FTP to my site. This repost is an attempt to get the previous changes posted. update 2008-09-11T19:12Z Well, added some interesting links as deeper analysis and pontification arises. I don't expect to add more unless Dare or Tim Bray chime in. update 2008-09-11T15:43Z Use full-size CMIS diagram from EMC (via Cover Pages) update 2008-09-11T15:35Z Repair handling of images and attract attention to the Service-Oriented Interface notion employed in the CMIS diagram. update 2008-09-11T15:17Z Add link to comprehensive Cover Pages compilation. I'm also praying that Blogger's FTP update succeeds sometime in the proximity to my submitting the post. update 2008-09-11T02:37Z Add links to additional resources at EMC and to add images/videos to the page. update 2008-09-11T01:15Z Added more links and information about the OASIS Proposed Charter for the CMIS TC.]

Document Interoperability: The Web Lesson

noreply@blogger.com (orcmid) — Mon, 08 Sep 2008 00:25:00 +0000

Technorati Tags: interoperability, IE8, web site construction, web standards, compatibility, conformance, document preservation, document formats, IE8.0 mitigation, HTML 5

[update 2008-09-08T00:24Z Cross-posted from Pursuing Harmony because of the overlap with convergence of HTML, web standards, and the IE80.0 mitigation that is touched on here.]

"are there alternatives to google groups search for searching old USENET messages? because groups date fielded search is teh broken."

-- Richard Akerman on Twitter, 2008-08-31

Be prepared for a dramatic shift in the reality of web-site browsing and the honoring of web-page standards. The pending release of Microsoft Internet Explorer 8 is going to put the reality of web standards and their loose adherence in our faces. Although Internet Explorer is indicted as the archetypical contributor to disharmony on the web, Internet Explorer 8 is going to challenge all of us to deal with the reality of our mutual contribution to the current state of affairs.

Here is a lesson, probably many lessons, for document interoperability and the way that standards for document formats evolve and harmonize, or not, over time.

The Web as Clinical Science

The movement from loosely-standard pages and their browsing to strictly-standard pages and standards-mode browsing will illustrate every aspect of the same challenge for office-productivity documents and the office suites that process them.

Web pages are the experimental drosophilae of digital documents. All aspects of dynamic convergence on standards, themselves evolving, and the forces of divergence, are demonstrated clearly and rapidly. I expect it to take Internet generations for significant convergence, with no static level of standards adherence anywhere in sight. It took us almost 20 years to get to this point on the Web; I figure it will take at least five more to dig out of it far enough to claim that there is a standards-based web in existence and in practice. I'm optimistic, considering that HTML 5, the great stabilization, is not expected to achieve W3C Recommendation status until 2012.

No document-interoperability convergence effort is anywhere close to the promising situation of the web as Internet Explorer 8, HTML5 implementations, and other compatibility-savvy browsers roll out over the next several years. It is useful to use that situation to calibrate how convergence and interoperability could work for document interoperability. There are significant technical barriers. The non-technical barriers are the most daunting. That should be no surprise.

Versioning in Document Use

I've written on Orcmid's Lair about the IE 8.0 Disruption. This involves changes in Internet Explorer 8.0 by which web pages are rendered in standards-mode on the assumption that pages are conformant with applicable web standards. In the past, it was presumed that pages were loosely-standard and browsers, also loosely-standard, made a kind of best effort to present the page. The consequences have been explained marvelously in Joel Spolski's post on Martian Headsets.

We are similarly relying on document-format standards as a way to provide for many-to-many interchange and interoperability between different (implementations of versions of) document-format standards and different (implementations of versions of) processors of those digital documents. That means we have a version of the loosely-standard documents with loosely-standard processing problem. We can't be strictly standard because the standards can't (and definitely don't) have strict implementations at the moment; and there are many ways that specifications and implementations have been kept loose by design. Accompanying that looseness by design is the the simple fact of immaturity among the contending document-format standards for office applications, particularly as vehicles for interoperable applications.

For office-productivity documents as we know and love them, there are five, count 'em five "official standards."

The "Official" Public Standards of Office Documents

For Office Open XML Format (OOXML), there is the ECMA-376 specification of December 2006. There is also the ISO/IEC 29500:2008 Office Open XML File Formats standard once it is made available. IS 29500 will have some substantive differences from ECMA-376. We won't have a solid calibration of the differences until the IS 29500 specifications are available and subject to extensive review.

For the OpenDocument Format, there is the Open Document Format for Office Applications (OpenDocument) v1.0 OASIS Standard issued 1 May 2005. There is also the ISO/IEC 26300:2006 Open Document For Office Applications (OpenDocument) v1.0 standard (also on the publicly-available listing). IS 26300 is for the same format as the OASIS v1.0 standard, but it is on a completely-separate standards progression. Appendix E.3 accounts for the differences of IS 26300 from the text of the May 2005 OASIS Standard. The first page of the IS 26300:2006 document (page 5 of the PDF) identifies its source as Open Document Format for Office Applications (OpenDocument) v1.0 (Second Edition) Committee Specification 1, dated 19 July 2006, derived from document file OpenDocument-v1.0ed2-cs1.odt; this is not another OASIS Standard, however.

The second and latest OASIS Standard for ODF is Open Document Format for Office Applications (OpenDocument) v1.1 issued 2 February 2007. This document is derived from OpenDocument v1.0 (Second Edition) Committee Specification 1, the same specification that is the source of content for ISO/IEC 26300:2006. The changes made to arrive at ODF v1.1 from the v1.0 (Second Edition) committee specification are detailed in Appendix G.4. There are some mildly-breaking changes from ODF v1.0 to ODF v1.1, mostly of a clarification or correction nature. There are a few additional features that have no down-level counterparts in ODF v1.0.

A third OASIS Standard, ODF v1.2, is under development. The current drafts, using a very-different organization from v1.1, are available as pubic documents of the OASIS Open Document TC.

We can expect to see more versions of ODF and of OOXML at their various standards venues. We'll be watching here on nfoWorks as the situation becomes even more chaotic. Notice that this diversity ignores the variety of divergent implementations of the various specifications.

Format Versions that Live Forever

It is possible for one document-format specification to officially supplant another, with the older specification deprecated. That has not been done so far with any of the five-and-growing document-format specifications, any more than it has been done for most of the versions of HTML specifications that have been recommendations of the W3C (and IETF before the development track moved entirely to W3C).

For example, the last full-up specification for HTML, the HTML 4.01 W3C Recommendation of 24 December 1999, has this to say about its immediate predecessor: "This document obsoletes previous versions of HTML 4.0, although W3C will continue to make those specifications and their DTDs available at the W3C Web site." This was possible because HTML 4.0 was young and there were important defects that 4.01 cured.

The HTML 4.01 specification continues with the following recommendation: "W3C recommends that user agents and authors (and in particular, authoring tools) produce HTML 4.01 documents rather than HTML 4.0 documents. W3C recommends that authors produce HTML 4 documents instead of HTML 3.2 documents. For reasons of backward compatibility, W3C also recommends that tools interpreting HTML 4 continue to support HTML 3.2 [W3C Recommendation 14 January 1997] and HTML 2.0 [IETF rfc1866 November 1995 and the IETF-obsoleting rfc2854 June 2000] as well."

The XHTML branch of specifications, originally derived from HTML 4.01, were intended as the basis for a future generation.

Meanwhile, there has been work toward both XHTML 2 and HTML 5.0.

HTML 5.0 is currently intended to exist alongside XHTML 1.x and its newer arrangements while also absorbing XHTML 1.x to some degree (by having an XML form). The current HTML 5.0 draft specifies legacy processing (in its HTML-syntax form) for variations of over 60 HTML DOCTYPE DTD flavors, extending back to HTML 1.0 and other variants. The intention is to converge HTML and XHTML 1.x under a consistent HTML 5 processing model with only no-quirks, some-quirks, and quirks modes. This is also intended to end the variation and extension of HTML (not XHTML) by capturing <!DOCTYPE HTML> for its own and having a concrete HTML syntax that is fully-divorced from both SGML and XML. It is important to point out that HTML 5 is not going to eliminate the divergence that browser (user-agent) plug-in models, plug-in implementations and scripting systems (especially client side) bring to the mix.

Document-format versions are not easily abandoned. Even if production of a format is deprecated, consumption of the format may need to continue into the indefinite future, and certainly so long as emitters of deprecated formats have significant usage. The W3C progression of HTML is at a point where that is fully-recognized and being honored in reaching toward an HTML 5 plateau sometime in the next decade.

Considering this promising stabilization, when would I manage to change all of my web sites and blogs to clean HTML 5 pages? Not until I know that visits to those sites are only a small fraction of Internet Explorer versions prior to IE8 (or maybe IE9) and other browsers lacking full-up standards-mode processing. Fortunately, the HTML 5 specification-effort promises to show me exactly how to do that in a mechanical way. I am looking forward to automated assistance. In my case, I'll also have the benefit of my IE 8.0 mitigation effort. Other web sites may require other approaches, and user browser choice will involve important trade-offs for some time.

I am surprised by the number of people who operate multiple browsers. Although I operate multiple products for office applications these days, that's mostly to explore their interoperable use, not to ensure ability to interchange documents (well, not until I joined OASIS and the ODF TC). I've been a serial adopter of Internet Explorer versions since IE 2.0. As a typical late-adopter, I may finally branch out now just to have a better calibration of the migration to standards-based sites and browsers for them.

This is an important lesson for the management of the expanding variety of specifications of formats for office-application documents, formats of which HTML packagings are sometimes one of the flavors.

Reconciling office-application document-format versions does not promise to be so easy as the current effort to stabilize HTML for the web.

The Looseness of Document Specifications

Of course, OOXML and ODF are not close dialects off a single family tree, as HTML variants might be treated (and HTML 5 demonstrates, if successful). In addition, the current specifications are not for same-conformance, interchangeable-everywhere documents:

There are weak conformance requirements. It is not necessary to implement any particular amount of the specified format: OOXML or ODF. This is by design. I don't expect that to change. There is also no way to indicate how much or how little is accepted and/or produced. Well, you could look to see what software produced the document, using ODF as our example:

<office:document-meta
    xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0"
    xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0"
    office:version="1.2">
<office:meta>
    <meta:generator>
        OpenOffice.org/3.0_Beta$Win32 OpenOffice.org_project/300m3$Build-9328
    </meta:generator>
</office:meta>
</office:document-meta>

This strikes me as even less appealing than the challenge of sites adjusting for browsers and browsers adjusting to HTML DOCTYPE declarations (and their absence).

It is not encouraging that the office:version attribute and <meta:generator> element are both optional. It is unfortunate that the office:version attribute is generally uninformative about the processing requirements for the document file in hand, serving merely as an automatic claim of one specification the document conforms to. The document is also likely to conform to earlier versions and probably ~~alter~~ later versions, although it is unclear how we can determine that easily for a given document representation.

Arbitrary "foreign" elements are allowed. I'm not clear how IS 29500 for OOXML will allow for this kind of thing, but the ODF specifications are justly-notorious for this provision (ODF 1.1, section 1.5):

"Documents that conform to the OpenDocument specification may contain elements and attributes not specified within the OpenDocument schema. Such elements and attributes must not be part of a namespace that is defined within this specification and are called foreign elements and attributes.

"Conforming applications either shall read documents that are valid against the OpenDocument schema if all foreign elements and attributes are removed before validation takes place, or shall write documents that are valid against the OpenDocument schema if all foreign elements and attributes are removed before validation takes place.

"Conforming applications that read and write documents may preserve foreign elements and attributes."

There are some further wrinkles and this proviso:

"Foreign elements may have an office:process-content attribute attached that has the value true or false. If the attribute's value is true, or if the attribute does not exist, the element's content should be processed by conforming applications. Otherwise conforming applications should not process the element's content, but may only preserve its content. If the element's content should be processed, the document itself shall be valid against the OpenDocument schema if the unknown element is replaced with its content only."

As a developer, I love gimmicks like this. But, basically, this only works with processors that re-encounter document files that they themselves produced. Anything more coherent requires that the implementers of different processors form some sort of out-of-band, separate-from-the-standard interoperability agreement on particular foreign elements and handling of office:process-content attributes. Users, confident that their software is "standard," will have frustrating and inexplicable interchange experiences (unless the usual thing is done and everyone agrees to lock in on the same software [version], surprise, surprise).
OOXML has a versioning scheme that might provide controlled extensions that degrade usefully when processed by implementations of down-level specification versions. It is unclear at this point whether this is just a more complicated way to end up with the same interoperability problems.
Some features require foreign content. Both OOXML and ODF have features where content is represented by a binary-data part elsewhere in the package. There is little (OOXML) or no (ODF) indication of what the format of the binary element is and what MIME types are allowed for such document components. All use of those features and any interchange agreements about them are beyond the current provisions of the relevant document-format standards.

There are other places where implementation-defined values are expected and are expected to be preserved by other implementations.
Some values and default selections are implementation-specific. I was mining in the ODF specification the other day. I did not expect to find attributes having text on these patterns:

"The value of this attribute is implementation [or application] specific."

"If this attribute is not present, the application might or might not display [whatever]."

These are relatively minor considering the amount of variability from the other conditions already mentioned. What's curious about these is the elevation of particular implementation-specific features as specification-favored. In the case of implementation-specific attribute values, there is also the interesting problem of a processor determining whether such a value is intended to have its implementation-specific interpretation or not. It appears that the related features will only be useful under tightly-restricted interchange conditions.

I will not be surprised to find similar looseness in the OOXML specification, IS 29500.

Prospects for Interoperable Convergence

We already have before us difficulties with interoperable convergence of individual progression of a single standard and its variety of implementation. This makes the prospect of harmonization between different standard formats rather murky.

Desktop office-application software has more promise with regard to application of Postel's Law, to be liberal in what is accepted and conservative in what is produced. Unfortunately, the current specifications do not require conservative, interoperable implementations; the current specifications are arguably antagonistic to such an achievement.

I suspect that this is an unintended consequence mixed with some inattention to what it takes for interoperability to be achievable.

It remains to see how our experience and understanding matures. We are at the beginning, not the finish. The journey may seem endless.

The process of IE 8.0 mitigation and preparation for a standards-mode approach to web browsing impacts this site and blog as well as every other web page I have ever posted (somewhere over 120MB worth and climbing).

I'm not going to say anything more about IE 8.0 mitigation and HTML harmonization here. The overall effort will be tracked in that category of Professor von Clueless posts; that's the place to follow along. The lesson for document interoperability is something that is definitely appropriate for Pursuing Harmony; there'll be much more to say about that.

Cybersmith: The IE 8.0 Disruption

noreply@blogger.com (orcmid) — Wed, 03 Sep 2008 03:07:00 +0000

Technorati Tags: interoperability, web standards, trustworthiness, IE8, usability, web site construction, compatibility, cybersmith

[2008-09-03T03:04Z cross-posted from Orcmid's Lair, capturing the post under the IE8.0 mitigation category here.]

I've elected to adopt the IE 8.0 beta 2 release as a tool for checking the compatibility of web and blog pages of mine. I see how disruptive the change to default standards-mode is going to be and how IE 8.0 is going to assist us. I need to dig out tools and resources that will help me mitigate the disruption and end up with standards-compliant pages as the default for new pages.

Looking Over IE 8.0 beta 2

I avoid beta releases of desk-top software, including operating systems and browsers. Because the standards-mode default of IE 8.0 is going to place significant demands on web sites, I also thought it time to install one copy of IE 8.0 simply to begin assessing all of my web sites and blog pages for being standard-compliant enough to get by. I am willing to risk use of beta-level software in order to be prepared for the official release in this specific case. I'm also sick of having IE 7.0 hang and crash on mundane pages such as my amazon.com logon. I'm hoping that even the beta of IE 8.0 will give me some relief from the IE 7.0 unreliability experience. And so far, so good.

With the promotion of beta2 downloading this past week, I took the plunge. Installation was uneventful and all of my settings, add-ins, favorites and history were preserved. My existing home page, default selections, menus and tool bars were also preserved. [I am using Windows XP SP3 on a Windows Media Center PC purchased in September, 2005. IE 8.0 beta 2 also seems faster on this system in all of its modes.]

I did not review much of the information available on IE 8.0, expecting to simply try it out.

My first surprise was a change to the address bar. There is a new format where all but the domain name of the URL are grayed. That was distracting for the first few days and it still has me stop and think. I realized this is the point: emphasizing the domain name so that people will tend to check whether they are where they expect to be. I like the idea, even though I have to look carefully and remember the full URL is there when I want to paste it somewhere or share the page on FriendFeed or elsewhere. I take this provision as one of those small details that demonstrates a commitment to safe browsing and confident use of the Internet.

What I was looking for, and saw immediately, is the new compatibility-view button. This "broken page" button appeared on the first site I visited after installation of IE 8.0 beta 2.

Clicking the button causes it to be shown as depressed and the page is re-rendered as a loosely-standard page with the best-effort presentation and quirks renderings of IE 7.0 and earlier Internet Explorer releases. If you leave the button selected, the setting is remembered and automatically-selected on your next visits to the same domain. It stays that way until you unselect the button by clicking it again while visiting pages of that domain. It was this feature that tipped-me over in wanting to check out my own pages using beta2 (although I thought the button was tracked at the individual page level until I read the description of domain-level setting).

By the way, if a page is detected to require a standards or compatibility mode specifically, no compatibility view option button is presented.The amazon.com site is this way from my computer, and so is Vicki's pottery-site home page. I looked at the source of the amazon.com site and confirmed that they are not using the special tag that requests that the compatibility view be automatic. I didn't check the HTTP headers to see if they are using that approach to forcing a compatibility or a standards-mode view. I know I did nothing of the kind on Vicki's site. This suggests to me that there is also some filtering going on in standards-mode rendering to notice whether a compatibility view should be offered. I'm baffled here. I am curious whether there is any browser indication when the compatibility view is selected by a web page tag or HTTP header. I suspect not and I'll have checked into that soon enough.

I also checked out the InPrivate browsing feature, which, although popularly dubbed the "porn mode," is very useful when using a browser from a kiosk or Internet cafe and when making private on-line transactions from home.

At this point, I am not interested in special features of IE 8.0 other than those related to improving the standards-compliant qualities of web pages and the browsing experience. I may experiment with other features later. My primary objective is to use the facilities of IE 8.0 and accompanying tools to improve the quality and longevity of my web publications. Once I have some mastery over web standards, I will look into accessibility considerations, another project I have been avoiding.

Disrupting the State of the Web

The problem that IE 8.0 is intended to help resolve is the abuse of Postel's Law [compatibility view offered] that the web represents: "be conservative in what you do, be liberal in what you accept from others." The abuse arises when what you do is based on what is being accepted, with no idea what it means to be conservative. The web was and is an HTML Wild West and it is very difficult to enforce conservatism (that is, strict standards conformance in web-page creation). Since browsers also varied in what they accepted and then what they did with it, loosely-standard pages and loosely-standard browsers have been the norm and web pages are crafted to match up with the actual response of popular browsers.

Since Internet Explorer is made the heavy in this story, we now get to see the price of changing over to "be strict in what is accepted and be standard in what is done with it." This is a very disruptive change. We'll see how well it works. Joe Gregorio argues that exceptions to Postel's Law are appropriate. Some, like Joel Spolski [no compatibility view], think it might be a little too late. There are already some who claim that the IE 8.0 Compatibility view is a sin against standardization [compatibility view offered], no matter that not many of the 8 billion and climbing pages out there are going to be made strictly-conformant any time soon. With regard to compatibility mode, I think it is foolish for it not to be there and Mary-Jo Foley is correct to wonder how much complainers are grasping at straws.

It was surprising to me to observe how regularly the compatibility-view option button appears and how terribly much of my material renders in IE 8.0's standards mode. Apparently the button is there because IE 8.0 can't tell whether the page is really meant to be rendered via standards-mode or is actually a loosely-implemented page. I'm spending a fair amount of time toggling back and forth to see if there is any difference on sites I visit. This suggests to me that there is going to be a rude awakening everywhere real soon now. It is also clear to me that I don't fully understand exactly how this works, and I need to find a way to test the explanation on the IE blog and the discrepancies I notice, especially when the compatibility-view option is not offered and I know nothing special was done to accomplish that on the web page I am visiting. I am also getting conflicting advice when I use an on-line web-page validator.

This change-over to unforgiving, default-standards-mode browsers is going to be very disruptive for the Internet. In many cases, especially for older, not-actively-maintained material, the compatibility view is the only way to continue to access the material successfully. There is a great deal of material for which it is either too expensive or flatly inappropriate to re-format for compatible rendering using strictly-standard features. Without compatibility view, I don't think a transition to standards mode could be possible. The feature strikes me as a brilliant approach to a very sticky situation.

Although there is a way to identify individual pages as being loosely-standard and intended for automatic compatibility view, that still means the pages have to be touched and replaced, even to add one line to the <head> element of the HTML page. There are billions of pages that may require that treatment. Perhaps many of them will be adjusted. That will take time. Meanwhile, having the compatibility-view option and its automatic presentation is very important.

There is also a way to adjust a web server to provide HTML headers that request a compatibility (or standards-mode only) view of all pages from a given domain. That strikes me as a desperate option to be used only when there is no intention of repairing pages of the site. I might do that temporarily, but only while I am preparing for a more-constructive solution that doesn't depend on compatibility view being supported into the indefinite future. The variations on the available forms of control (browser mode, DOCTYPE, HTTP header, and meta-tag) need to be studied carefully. I expect there to be confusion for a while, probably because I am feeling confused with the ambiguities in my experience so far.

Another problem, especially with regard to IE 8.0 beta2, is that we don't reliably know how badly a loosely-standard page will render with a final standards-mode browser versus the terrible standards-mode rendering that beta2 sometimes makes at this time. It is conceivable that the degradation might not be quite so bad as it appears in beta2, but there is no way to tell just yet.

The need for expertise and facility with semi-automated tools as part of preserving sites with standards-conforming web pages is probably a short-term business opportunity. The web sites that may be able to make the transition most easily may be those like Wikipedia, where the pages are generated from non-HTML source material. (That makes it surprising that Wikipedia pages currently provoke compatibility buttons and compatibility view is needed to do simple things like be able to follow links in an article's outline.)

Mitigating IE 8.0

To mitigate the impact of IE 8.0 becoming heavily used, it is necessary to find ways to do the least that can possibly work at once, and then to apply that same attitude in making the next most-useful change, and so on, until the desired mix of standards-compliant and loosely-compliant pages is achieved.

To find out what tools are available along with IE8 beta 2, these pages provide some great guidance and resources:

Ed Bott 2008-08-28: An IE8 Beta 2 Q&A
IE8 Blog 2008-08-27: Internet Explorer 8 Beta 2 Now Available
Microsoft: Windows Internet Explorer 8 (beta): Home Page
US ISV Developer Evangelism Team: Consumers Begin Using Internet Explorer 8 Beta 2
MSDN online: META Tags and Locking in Future Compatibility (preliminary), with details for how to mark pages and also set the sites HTTP response headers (not for the faint-hearted)

That should point you to all of the resources you need to understand how to check sites, how to use the compatibility provisions, and other ways to take advantage of IE8 availability when it exits beta.

I'm looking at a progression that will allow the following:

Have a complete site automatically set to be browsed in compatibility mode (EmulateIE7, in my case), buying time to provide finer grain solutions
Modify templates on blogs such as this one to specify compatibility mode on all new and updated pages until I say otherwise
Find a way to make bulk changes to pages, adding a <meta> head element that specifies compatibility mode for those pages
Decide how to migrate pages so that their results are delivered best in standards mode. This may be a very long-term approach that doesn't begin implementation until the percentage of old browsers still in use diminishes enough to have standards-mode browsers be dominant. There should still be a substantial period of time while compatibility mode is grand-fathered by the latest browsers.
Even if compatibility modes eventually disappear from popular browsers or whatever comes after the browser, there will be a lasting need for compatibility view of archival materials, or some other creative solution that allows those materials to be accessed in a standards-mode world.
There will be future breaking changes in standards mode as updated/successor standards are introduced. The compatibility view requirement may never disappear, although its future achievement may be accomplished with less disruption. Unless, of course, we fail to learn the lesson.

I will work out my own approach on Professor von Clueless, since I have definitely blundered my way into this.

This post is also being used to identify the IE8 mitigation required for this blog, along with some other improvements:

It is a prospect for assessment of standards-compliant presentation via IE8 beta 2.
It is my first use of Blogger Labels (Categories in other blogging systems) to archive Orcmid's Lair posts by categories as well as having weekly chronological archive pages and the buckets of individual posts made in the same month.
I am setting up Windows Live Writer image-uploading capability to FTP images to a directory of the blog; the images in this post are the confirmation of that.

When I update the template to force compatibility with the current loosely-standard blog-page generation, this post will reflect that too.

[update 2008-08-30T16:42Z I had a few clumsy bits to clean up, taking the opportunity to elaborate further in some areas. The disruption with standards-mode web browsing is a great lesson for standards-based document-processing systems and office-suite migrations toward document interoperability. I'm going to pay attention to that from the perspective of the Harmony Principles too.]