I'm just completing a total reinstall of Windows on my Windows Media Center.  Not much fun.  I was having strange behaviors and finally trouble booting, and my attempts to reinstall Windows in place simply corrupted the system.  Eventually I learned my video card was burning up (not surprising running 24/7 in a poorly ventilated space for 3 years) and picked up a replacement.  By that time a total reinstall seemed the most likely way to regain some stability.

Anyway, enough whining.  The point of this post is that in order to remember the installation procedures and tricks I turned to - previous postings in this very blog.  Searching on "site:auburnmarshes.spaces.live.com media center" gave me a list of all the tricks I used previously to install the system.  The knowledge I recorded there to increase the knowledge base of the world in a miniscule way, turned out to benefit me.  I noticed Jon Udell recently doing the same thing - blog posting things he wanted to remember in a searchable archive - the World Wide Web.

Maybe that's why many blog posts don't seem relevant to anyone but the author.  But useful to one is better than useful to none!

One headache though - I'd purchased a DVD decoder from nVidea.  Yet when I dug up the links in the invoice to download a replacement those links were all dead!  Important links such as download locations and customer support should remain stable.  Anything in an invoice should remain stable.  Or at least redirect to the closest current equivalent.

Worse than that, after a mere 12 months, my account (forced upon me in order to purchase) had been terminated, and couldn't be found even though the site advertises that they provide a stable re-download for two years.  They even removed the free 30-day trial downloads that would probably would have got me back on my feet.  I eventually found an install backed up locally so I didn't have to wait for their customer service to get back to me (if ever.)  Anyway, my anti-props to nVidea.  Fire the webmaster.

Also the Microsoft OneCare UI now crashes.  So the firewall is activated but you can't change its settings.  Guess it never ends does it...

I was at the farmers' market last week and the local citrus stand had, among the oranges, lemons, and grapefruit, what looked like an elephantine lemon and labeled "shaddock."  I was intrigued and inquired what the difference was between that and a pomelo, and whether this would be appropriate in my favorite Thai pomelo salad.  The proprietor, not having much of a run on his bushel of shaddocks, simply gave me one for free to try out.

Wikipedia doesn't distinguish between pomelos and shaddocks, though the shaddock does seem to be a slightly different variety of pomelo with a thicker skin.  This one has a diameter of about 6 inches including at least an inch of rind.

I had this salad several times in Bangkok years ago, and I haven't yet recreated it to my entire satisfaction (somehow I'm missing one of the earthy undertones) but it's pretty refreshing nonetheless.  I promised myself that I'd write up the recipe to give the vendor so he could boost his shaddock sales.  Here 'tis!

• 1 pomelo or shaddock
• 1 lime, juiced
• 1 T fish sauce
• 1 T palm sugar (or white sugar if you must)
• 2 cloves of garlic, pressed
• thinly sliced chilis to taste (or a few pinches of red pepper flakes)
• 1/4 cup peanuts, roughly crushed
• cilantro
• mint
• deep-fried shallots (available in jars at international markets, or make your own.)

Shred the pomelo into pearls, keeping them intact as much as possible.  For me this takes about 20 minutes.  Some images on how to do this here (decent looking alternative recipe as well!).  Dissolve the palm sugar in the lime and fish sauce.  To taste it should be equal parts salty, sweet, and tangy, though since in this case it's going on more citrus I usually under-represent the lime a bit.  Add the garlic and chilis, and toss it over the pomelo, cilantro, and mint, and peanuts.  Top with the deep-fried shallots, and enjoy!  Each pearl pops in your mouth and releases it's juice.

If I'd had any, I would have also tried adding:

• 1T super-thinly sliced lemon grass
• chiffonade of kaffir lime leaves

The next week, my wife went back and mentioned how much we'd enjoyed the shaddock.  He simply handed her the entire last bushel of the season.

Clearly the pomelo industry needs our support!  Do your part today.  You'll be glad you did!

(Still throwing off random sparks ignited at the W3C Enterprise Workshop.)

Technology, like religion, eventually begins to accrete dogma.  In the case of the Web there seems to be a growing trend of thinking that if something has proven to be "good", alternatives to that thing must be alternatives to "good", and we all know the only alternative to "good" is "bad," right?  If Mohammed is the true prophet, Jesus can't be.  If REST is good, WS-* can't be.

A case in point:  The fact that a URI can be communicated in plain text and thus in a wide variety of contexts is viewed as a great strength of the web.  The fact that one can write a URI in an email message, in a print publication, or even on the side of a bus is often touted as a virtue of URI identifiers.  The ability to write a URI on the side of a bus is undoubtedly good.  An identifier that can't easily be transcribed onto a rolling billboard thus must be bad, right?  Paul's hilarious graphic of an EPR on the side of a bus is an example, with the implicit message that because URIs are good, EPRs must be bad.

Although Paul was partly making a different point, taking this incipient dogma too seriously is misguided.  Very few of the URLs pointing to interesting resources on the web are actually simple enough to write on the side of the bus and survive human transcription.  Paul unfairly compares an EPR of horrible complexity to a simple URL.  Only a small percentage of the URLs in use today are simple enough to be placed on that bus with a reasonable chance of success.  And even the simple ones rely on years of forced adaptation to make such finger- and tongue-twisters as "haytch-tee-tee-pee-colon-whack-whack" even nominally acceptable.  Just because human transcription is good for some identifiers, should one conclude that it must be a quality desirable for all identifiers?  Are long and complicated URIs "bad"?  I argue that they simply aren't appropriate for use in the context of human transcription.  EPRs are specifically designed for use in the context of Web services - i.e. machine-to-machine communication on the web.  I seriously doubt that machines are going to be reading sides of busses.  And if they do, verbosity is still unlikely to be one of the primary problems.  The goodness of a URI on the side of a bus doesn't imply the overall badness of EPRs.

In the context of machine-to-machine communication, often more structure is better.  A structured identifier can indicate the split between metadata and data.  It can have definite rules about where the identifier starts and ends - wouldn't it be nice if plain-text email readers could detect the start and end of multi-line URLs?  It can have a uniform syntax for describing the "parts" of the identifier - URIs embed a pretty complicated microsyntax.  It can have simpler, more uniform rules for encoding special characters.  It can put the information necessary to access a particular resource within the identifier instead of hiding it in cookies and session state as is common in HTTP resources.  I'm not claiming that EPRs are all good, just pointing out that within a given context perhaps they aren't all bad.

Another example of a bit of good advice turned into dogma and used to bludgeon the innocent was evident in Nick Gall's W3C Enterprise Workshop paper claiming:

Nowhere in the vast multitude of WS-* specifications or the articles or papers describing them is there any imperative or even any emphasis that a Web Service should return an XML document that is populated references to other Web resources, ie URIs.  But it is a fundamental principle of the Web that good Web resources don't "dead end" the Web; instead, they return representations filled with URIs that link to other Web resources.

First of all, I'm wary of even dignifying this so-called "principle" with that label.  For human interaction, for searching and cataloging based on simulating human navigation patterns, pages full of links are good.  Especially when the content of that page isn't terribly useful it's nice to be able to click virtually at random and escape into the soothing world of advertising pitches.  But for a particular user, the majority of links in a page never get used.  What is a machine going to do with a bunch of random links?  In machine-to-machine communication, links are undoubtedly going to be much fewer in quantity, but much higher in quality.  And if the service is doing something useful on behalf of a user that doesn't require the transmission of lots of links, is that therefore a bad service?  A service should return precisely the number of links necessary for it to do useful work.  No more, and no less.

The danger of dogma is that it takes something that is right and useful in context, and applies it to contexts where it often is neither right, nor useful.  Apply Cold War politics to the so-called War on Terror and you get Iraq.  Apply Jesus' celibacy to much less spiritual theocrats and you get sex abuse.  Apply something like the carefully constrained Web Architecture out of context and the consequences aren't nearly so disastrous - but you will look kind of silly.  Best to keep it to a minimum.  Ideally, no larger than will fit comfortably on the side of a bus.

The WSO2 Oxygen Tank, hosting our open-source code, documentation, articles, mail forums, and so forth, also now hosts a series of podcasts, now including one by me.  I spoke with Hasmin Abdulcader about the W3C Workshop on Web of Services for Enterprise Computing, reiterating some of the points in my previous blog post.

Also check out Jon Udell speaking with Steve Vinosky prior to the workshop - that's much more insightful about the REST versus WS-* debate about which I don't have a whole lot new to say at this point.

Photocredit - me trying to give the mic away at the Workshop by Paul Downey.

Moments ago, the Web Services Description Working Group voted to move WSDL 2.0 to Proposed Recommendation, culminating over 5 years of effort by the likes of Charlton Baretto, Allen Brookes, David Booth, Roberto Chinnici, Glen Daniels, Paul Downey, Youenn Fablet, Martin Gudgin, Hugo Haas, Amelia Lewis, Tom Jordahl, Anish Karmarkar, Jacek Kopecky, Kevin Liu, Philippe Le Hegaret, Jeff Mischkinsky, Jean-Jacques Moreau, David Orchard, Gilbert Pilz, Tony Rogers, Arthur Ryman, Jeffrey Schlimmer, William Vambenepe, Asir Vedamuthu, Sanjiva Weerawarana, and Ümit Yalçinalp.  And I could go on and on...

Congratulations and many thanks to all for the hard work getting us here!  Still a bit of work to do to get these specs published and then approved as Recommendations, but I'm confident the road from here out will be smooth and largely administrative.