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.