I am now posting on a regular basis on the David Janes' Code Blog.

David Crow scores big for future TorCamp TorDemoCamps.

This morning Mark Kuznicki and I met with Allen Gelberg, Director of the Collaboration Centre at MaRS. Allen has offered to sponsor future DemoCamps. The MaRS sponsorship would be for space and facilities for 10 events throughout the year. Allen and MaRS donated the space for DemoCamp4 and they were impressed by the openness, the energy and the people that attended (see I told you it was about the attendees ;-). This sponsorship would include the facility rental for the MaRS Auditorium which is roughly $2,500/night, that’s a $25,000 donation of in-kind services (Kristin might argue my not working would count as an equivalent or larger donation). There are a few conditions of the donation of space, including:

1. Guarrantee that the space is used by BarCamp/DemoCamp for the purpose outlined (an open space for people to share, learn and get excited about technology and what is going on online)
2. We may be bumped by a paying customer
3. We use preferred MaRS services including catering

BarCamp is inline with the MaRS mission of “accelerating the commercialization of new ideas and new technologies by fostering the coming together of capital, science and business.” Part of the discussion is that not all of the topics at BarCamp are commercialize-able and there is no reason that they should be, BarCamp is a place for people to share, learn and get excited about technology and what is going on online.

I was at MaRS for the iSummit conference and it’s a very nice facility, with great access to transit and nearby socialization nexii (i.e. bars)

I’ll be demoing the BlogMatrix Platform at the next DemoCamp on the 25th of April. This will be significantly different than what you see here even though the underlying software’s the same (well, with four more months of development). We’ll be showing structured blogging/CMS, mapping, calendaring and microformats all rolled together and if you’re lucky we’ll be showing some projects we’re doing for paying clients (along the lines of this in terms of navigation).

It’ll be sad though, IMHO, if MaRS is the only venue used for TorDemoCamp. We’ll have to see if the crowds (150+ at TDC4) keep growing.

Tagged: microformats, Toronto, DemoCamp, TorDemoCamp.

Possibly in response to my post on Jon Udell and Microformats, Upcoming has “added hCard info to all our venues and events on Upcoming.org” (here). Their official notice is here.

The reason you should care about this is that this allows venues and locations to be transparently copied between different event services without having to use proprietary “venue IDs”.

Again, sweet.

Tagged: microformats, hCard, Upcoming.

Google has released Google Calendar.

I got burned several years ago by using an online calendar, the name I forget, that was bought by Palm and then closed down after the crash. So if I’m going to use an online service seriously, I’m looking for a business model, otherwise forget it. Fortunately, Google is Google so there we go; however…

1. Where is my Upcoming.org import?
2. Where are the tags?
3. No Microformats?

… says Tara. Yes. In particular, why can’t I import continuously an RSS feed with iCalendar enclosures or even better an Atom feed with hCalendar embedded objects or even better than that an XHTML page with hCalendar.

Just think about that last scenario — just point at a page that has events and your calendar automatically gets updated as the page changes. No need for a specific Upcoming or Eventful import or hunting down syndication feeds.

100% disclosure — I’m working on a tool that (as part of a lot of other functionality) exports calendar events in hCalendar, so this would make my demos very very sweet.

Tagged: microformats, hCalendar, Google Calendar.

Matt Mower:

I think we already have the answer [for an export format for a blog]: RSS. It’s already a natural format for holding the essential data of a weblog and namespacing is an easy way to store the tool-specific data. A tool that understands another tools metadata (e.g. ENT topics) can import it, a tool that cannot can safely ignore it. Actually why are we even discussing this?

The real question seems to me to be: how best to use RSS for this purpose? Do we have one gigantic RSS feed for a weblog? In my case with about 2100 posts it would be pretty big and unwieldy. Back in 2004 Paolo and I were talking about how to do weblog archives.

I was messing with an approach that combined RSS and OPML to create a weblog archive. For each post/day/month (pick your granularity) create a corresponding RSS feed of weblog entries. These feeds are then referenced from an OPML file that defines the overall structure of the archived weblog. In this way you can quickly narrow down to find an individual post, or suck up the whole thing (useful for tools like Sigmund).

Danny Ayers:

I’m sure RSS+OPML would be doable, but it seems like building on quicksand given the nature of those specs. The RSS part could certainly be productively flipped to Atom. I’m not sure whether there’s anything spec’d up yet for the role of the OPML file – the Collections of the Atom Protocol should be pretty close.

[...] Another alternative would be to use HTML. Done systematically there’s potential for a neat export/archive system. Conventions are already available for the core of this kind of stuff with microformats – hAtom for entry/feed level data, XOXO for broader, site level structure etc.

I can think of three advantages right away of using microformats over RSS+OPML. The clearest being that it would be using proper specs, well-defined and none of that silent data loss nonsense. There’s more flexibility because the representations can be freely mixed, it’s all HTML. You can’t mix RSS and OPML in the same document. The third is the big pragmatic gain that a level of partial understanding comes for free. The stuff is HTML, a browser can make a useful rendering of that out of the box.

I noted in Danny’s comments (slightly rewritten):

hAtom, in my mind, was always the first step [of a blog-post microformat]. The second step was to make a microformat for marking up archive lists that you see on sidebars. This (in my mind) would not require XOXO, though it would work with it if it’s there.

It’s then only a matter of constructing a URI pointing to the uFed archive (probably the blog’s home page + a fragment) and we can walk the blog in a structured, ordered method.

If I progress down this route, I’m considering offering a bounty to Wikize all “examples on the net”, just to save time.

Jon Udell does a screencast demonstrating Live Clipboard and microformats. At the end he runs into an interesting problem: how do we translate locations from Eventful to Upcoming?

Both Eventful and Upcoming encode their locations as “IDs”. The common location Jon is talking about is “Colonial Theater, Keene, New Hampshire 03431”. In Eventful, this is venue_id=3669; in Upcoming it is venue_id=V0–001-000150985–3.

Jon suggests that we flatten the venues into a “tag” that can be easily matched, e.g. UniversalVenue_03431_ColonialTheater. Now, sure, we could do that if we wanted to, taking into account this doesn’t deal with other countries, variantions on spelling (I started search for “theatre”, like a good Canuck), and so forth. In fact, Eventful’s encoding of the name (with ”(New Hampshire)” added) makes the likelyhood of a match in the case of this example pretty low!

I’ll suggest there’s a better way to do this, and it’s right in front of our faces: URIs and the hCard microformat. Instead — or in addition to — accepting “IDs” as location, accept a URI that points to a hCard. Here’s a screenshot from Jon’s demo:

In either case, simple replace the value for “venue_id” with the URI for the venue from either service. I.e.

• venue_id=http://eventful.com/venues/V0–001-000150985–3, or
• venue_id=http://upcoming.org/venue/3669/

At each of these locations we expect to find a hCard. Alas, Upcoming doesn’t (yet) but Eventful does. Click here to see it.

This becomes even easier if the venue had it’s own URI and hCard!

Now all the service has to do is grab the hCard from the URI, parse it, and use a heuristic to compare to whatever’s already in the service’s DB. This can be cached for efficiency; unknown locations can be added to the DB or ignored depending on what is desired. I’ll suggest this solution will be both in practice and conceptually better than the tag solution, as the encoding mechanism is very flexible, the matching heuristic has a lot more to work on if there isn’t an exact match, non-matches have a possible/obvious solution, and URIs provide a great way of “world-wide encoding” information that tags don’t necessarily have.

Tagged: microformats, hCard, hCalendar, Live Clipboard

Randy Morrin writes:

At the GTA bloggers meet last night, I met up with David Janes. David is founder of BlogMatrix, a podcast hosting service [hopefully a lot more than that public in about 4 weeks — dpj] and author hAtom, a micro-format standard. hAtom embeds Atom (the syndication format) types into XHTML micro-format classes. I’ve always been one to ask “Why not just embed an extension element into the RSS?”

I’m looking at a blog entry—HTML in my browser—right now that potentially has several pieces of microformat embedded in it: Randy’s hCard, my hCard, the GTA Blogger’s event, and so forth. I want to go from looking at it to doing something with it. Let’s assume the microformatted information is in the RSS feed rather than directly embedded in the RSS. What procedure do I follow to go get that data?

Followup question: I’m looking at something from Randy’s archives: this arbitrarily choosen item. How do I get to the RSS item that encodes it (and potentially any metadata it had)?

Tagged: microformats, RSS, hAtom

(From an e-mail I wrote earlier today).

I thought I’d give you a better answer on why hAtom should be supported (by blogging tools). hAtom has the same potential benefit of any other (HTML-based) microformat—it will allow applications to deal with objects in a blog as a natural chunk. For example, ”reblogging” an entry (i.e. responding to someone else’s blog post), contact the author of this post, take the authors of this post and add to my address book, print this blog post (without all the comments, blogrolls, etc), and so forth. Search engines would be able to know in exactly what microcontent chunk a piece of text is in, rather than “it appeared on the front page of instapundit”. If people reblog using hAtom, it becomes easy to generate BLOCKQUOTE and Q elements with the correct CITE information and now we can start reliably linking in place conversations on the web.

hAtom also has the benefit of being a natural “microcontent container” so that other microformats in the future can be composited on top of it. I’m considering my next project in the blog/microformat space to be a “blog archive” microformat; combined with hAtom, this will give tools and people the ability to walk through weblogs in a structure fashion.

I know there’s a hand-wavingness quality to this argument—these tools do not exist. However, the bootstrap for this is quite small—the amount of work it is to put hAtom into a weblog template is less than 30 minutes work and it’s easy to test a validate that that will continue to work. Once there’s hAtom content out there, Javascript, Greasemonkey, TIDY + XML parsers in many languages will make it easy to get the content out. We’re already seeing this happening with hCalendar and hCard.

Interestingly, a lot of people on the microformats list think this is a way of combining syndication into HTML. I do not. Why? 1. size, 2. crud. First RSS provides a channel for delivering the data that’s relevant for syndication; a weblog is… well, a weblog, and usually much bigger. Size does matter and I don’t think hAtom will ever be used for syndication in more than a fringe # of cases. Secondly, if people can barely compose legal-XML for RSS and OPML, what’s the hope for correctly formatted XHTML delivered content? IMHO: none. Thus, you either have to have a super-parser available like Mozilla’s (and not that many of the apps I’m talking about above will already have access to a parsed DOM in the browser!) or they will run the result through TIDY, which is CPU intensive and less than guaranteed to have a happy ending.

Just to briefly bring up this discussion I had with Randy [Morin] on “why not just store it as XML”, as per his resume example. Last night I quoted the 2NF of DB development—i.e. don’t duplicate your data. If we didn’t have hAtom, how could you write the reblogging tools, the printing tools, etc.? Cross reference through the RSS? I’ve tried doing that and it’s surprisingly difficult because as an outside tool person, there’s no guarantee that the URIs match up and whether you can know all the text is there and what format it is in. So likewise with all microformats: if I have someone’s contact information as HTML (which is being eyeball-validated on a continual basis), why encode it as XML when I can just embed the semantic information in place.

Tagged: microformats, hAtom

I’ve converted the main index, category and monthly archives of this blog to hAtom. You can see a parsed example of this blog here.

See it here.

Bill Gates likes microformats. I guess that’s why they’re using them.

Something I forgot to mention: hAtom 0.1 is now official. Expect more from me on this soon—I’ve been very very busy but this is fairly important to some tech plans I’ve been working on.

Ray Ozzie writes285.entry?_c11_blogpart_blogpart=blogview&_c=blogpart#permalink:

I’d like to extend the clipboard user model to the web.

A few weeks ago, I approached my brother Jack – who leads a Concept Development team in my group at Microsoft – and visually sketched out and storyboarded some end-to-end user scenarios that I wanted to try to accomplish. The scenarios were all centered on this new clipboard user model.

The team took me up on the challenge, and in a few short weeks had accomplished all of the scenarios, and more. And they did it using techniques that are incredibly simple, and which work securely and are browser independent.

What does it do?:

Live Clipboard lets you copy a structured data object—for example, an address card—from the browser to “somewhere else”

How does it do it?:

It converts the DOM into an ugly but “safe” string using URI percent encoding embedded inside an XML document with root element “liveClipboard”. See the bottom of this post for an example.

Try the demo here.

The clever part:

Ozzie’s team at Microsoft has done something cool and original here, albeit built very much on others people work that hasn’t been credited properly. They are providing a common format for copying data out of the browser (alas, as text, see below) and paste it elsewhere (including back in the browser). I.e. browser + clipboard + envelope format.

The uncredited hero:

The demo is build around microformats; in particular hCard and hCalendar. As far as I can tell (I haven’t listened to all the screencasts), Ozzie did not credit the incredible amount of work that Tantek and others put into this—and it is integral to what Microsoft demoed.

Ah… sorry, they take credit for writing hCard and hCalendar.

We’ve defined small XML schemas, microformats that represent the data elements that we might be able to exchange between sites. Where is the clipboard of the web. What is the thing that lets people get information from one site, one web app to another as easily as it’s possible to do today with GUI-based apps.

The kludge:

As far as I can tell, they haven’t written a tool to examine the DOM and write it into a copiable string. Instead, the page is generated all from Javascript and the same code is used to create the clipboard buffer. There was no need for them to do this: Vyacheslav Smolin wrote a cool little piece of Javascript called HTML2XHTML that will work right off the DOM!

Things you may not have noticed:

Drag the scissors from the “demo”: and drag it to a text editor. Cool, eh? However, if you have Microsoft Visual C++ installed, run IDataObject Viewer. Notice that there’s only two clip formats there: CF_TEXT and “Unknown Clipformat”. It would be nice if this had a detectable format so that then you could properly detect a paste or drag and drop.

Other applications

My ‘microfomats-find’ Greasemonkey script (here) provided a popup menu when you clicked on the icon. (This script no longer works because the Greasemonkey no longer trusts the script authors and disallows a lot of the DOM operations the script used). I’m mentally kicking myself for not making the leap to wrapping and copying this!.

A LC object could be wrapped around an RSS button to encode all the feed information, including different available types: RSS 2.0, RSS 1.0, Atom, OPML, XOXO etc. Clicking on the button could then give you the option of not only selecting the feed or directory but also which service (something on your computer, BlogLines, Yahoo, etc.) you want to use to do the subscription.

In fact, this clicking on the button could possibly be generalized to call down to your computer (using a special extension or MIME type) to bring up a smart selector app that uses the LC data.

What people are saying

Marc Canter loves the idea and suggests using structured blogging for the format (I don’t think he knew that microformats was being used—that’s OK, Canter told me at Mashup Camp that SB “fully supports microformats” and there’s a fair amount of convergence on models).

Dave Winer writes something. He does not seem to be aware that quite a bit of work has been done already to provide the underlying data model for transfer.

Richard MacManus things it’s very similar to RedirectThis. This, BTW, it the reason I spent the last 5 months or so working on hAtom—I thought that the need for a redirect this tool would be alleviated if there was a deeper semantic markup of blog postings on the web (i.e. since then tools that could deal with other objects could also deal with this).

O’Reilly Radar transcribes Ozzie’s speech.

Dany Ayers: Microformats! Whoop whoop!

Sample:

This is one continuous line, which I’ve broken into multiple parts. I think it would have been better if they just base64 encoded the data—it would be a lot friendly for text editors, though obviously a little less readable!

%3Cdiv%20class%3D%22vcard%22%3E%3Cdiv%20class%3D%22n
%22%3E%3Cspan%20class%3D%22given-name%22%3EMatt%3C/span%3E%20%3Cspan%20class
%3D%22family-name%22%3EAugustine%3C/span%3E%3C/div%3E%3Ca%20class%3D%22email%22%20href
%3D%22matta@microsoft.com%22%3Ematta@microsoft.com%3C/a%3E%3Cdiv%20class
%3D%22tel%22%3E%3Cspan%20class%3D%22value%22%3E425%20707%207716%3C/span
%3E%3C/div%3E%3Cdiv%20class%3D%22adr%22%3E%3Cspan%20class%3D%22type%22
%3EWork%3C/span%3E%3A%3Cdiv%20class%3D%22street-address%22%3E1%20Microsoft
%20Way%3C/div%3E%3Cspan%20class%3D%22locality%22%3ERedmond%3C/span%3E%20
%3Cspan%20class%3D%22region%22%3EWA%3C/span%3E%20%3Cspan%20class%3D
%22postal-code%22%3E98052%3C/span%3E%20%3Cabbr%20class%3D%22type%22%20title%3D
%22dom%22%3EUSA%3C/abbr%3E%3C/div%3E%3C/div%3E

Update—from Danny:

  



      O’Reilly Emerging Technology Conference:

      March 6

      , at

      San Diego, CA




      

      

    

  

Via Danny Ayers, we learn of something called ”triple tags”:

Users are great and smart and do cool stuff, you can't stop them. Therefore it's no surprise to see them constantly pushing things to the limit, and this is why we're seeing the start of curious tagging methods.

Let’s look at the obvious one that I deal with…

geotagged
geo:lat=53.1234
geo:long=-2.5678

The second two tags have three parts; its namespace ‘geo’ and a key/value pair ‘lat=53.1234’. Because most tagging systems don’t allow us to search with wildcards, you can’t find all items tagged with ‘geo:lat=*’ for example, we also use a declarative tag ‘geotagged’ which can be used for searching.

Anyone can follow this [namespace]:[key]=[value] convention. If I wanted to sell my bike, I may add a photo of it to Flickr and add the tags:

selltagged
sell:price=79.99
sell:currency=dollar

There’s the declarative tag and two TripleTags. If it gained traction and enough people did it, then it’s easy enough to build a website or services that handle the searching and tagging of photos of items people want to sell. Once they’ve be sold the tags are automatically removed.

Combine these with geotags and you can find items near you that are for sale.

This is actually a problem I’ve been working on for the last four months (and thinking about for about nine) at BlogMatrix: namespaces with tags and how do you associate key=value data with URIs (tags are basically an association of key=True with a URI, or maybe assertions?). Here’s where my thinking is:

• instead of added a tag ‘geotagged’, why not automatically add a tag recognizing namespaces—‘has:namespace’. For example, if a post is tagged ‘sell:price=79.99 geo:lat=53.1234 geo:long=-2.5678’, automatically add the tags ‘has:sell’ and ‘has:geo’. It’s very neat, flexible and doesn’t require much (any?) effort on the user.
• I’m pretty uncomfortable with tags like ‘geo:lat=53.1234’. I mean, they’re not really tags, are they, because we’re not really looking for an exact match for the string ‘geo:lat=53.1234’ and one could see the tag namespace filling up with a lot of semi-equivalent giberish. Why not explicitly recognize this as a key/value pair? Of course, the problem is that del.ico.us, etc., don’t have this metadata concept.
• There’s synergy here with the xFolk microformat.
• slightly off topic, BlogMatrix reserves all tags beginning with the ’:’ for internal use—i.e. the empty namespace. This lets us do all sorts of internal tagging tricks without letting the user accidently (or deliberately) upsetting the model

Tagged: xFolk, triple tags, Blogmatrix.

JAHAH 0.1.2 is available. It features:

• much improved error trapping/reporting in jahah-include
• absolute URI rewriting in jahah-include
• a partial failure mode (that returns the body) for unparsable HTML documents
• a new demo that you can easily copy to your own site to show the cross-scripting

Tagged: jahah.

(This is from a posting to the microformats-rest group).

I came to this by a slightly strange path—I wanted a way of providing webservices that others could load into their own webpages. “traditional” AJAX, if there is such a beast, cannot do this because of limitations with cross site scripting.

I mulled this over for a while and discovered at Christmas time that one can use the SCRIPT element to dynamically load scripts from anywhere. I had also been looking at a technology called JSON which has huge replacement to be a widely used net transport language, as it’s much easier to deal with that XML. JSON led me to Bob Ippolito’s JSONP, which lets me combine the SCRIPT with JSON with a callback.

Finally, looking back through my notes, I revisited AHAH which provided an easy method for producers and consumers to use HTML in “AJAX-y” applications.

Combining them all together, I’ve produced JAHAH (pronounced the German way):

• it allows cross site scripting
• if the “jsonp” parameter is not passed to the webservice, HTML documents are returned
• if it is, a simple JSON payload is returned with “html” holding the HTML document; arbitrary other data can be added to the payload

I’ve written a deeper description here, the official home (please don’t like to the temporary redirect) and I’m providing code samples, JAHAH webservices for extracting HTML from files or looking at RSS feeds, and all my sources. If you’d like to publicly comment or link to it on a blog, please also link to here. My code also builds on Ippolito’s MochiKit.

Tagged: ajax, ahah, json, jsonp, web2.0, jahah, microformats.

This page is permanently available here.

What is JAHAH?

JAHAH is an AJAX-like technology for 'mashing' web pages together.

• It is easy for web page authors to include JAHAH documents
• It is easy for content producers to create JAHAH documents
• JAHAH documents can be included "cross-domain", unlike most AJAX technologies
• JAHAH documents are search engine friendly

Where does JAHAH come from?

JAHAH is based on existing ideas and technology:

• AHAH is technology for directly including HTML fragments using AJAX
• JSON is a scripting-language friendly way of transmitting data across the web (that works cross-domain)
• JSONP is an incremental improvement to JSON that allows the document requestor to specify an arbitrary prefix to be returned prepended to the result

JAHAH Web Service Description

A web service that provides JAHAH documents must behave as following:

• If there is a 'jsonp' parameter, it must return:
  • the value of that parameter, followed by
  • if everything's OK, a dictionary with 'html' containing the payload
  • if there's a problem, a dictionary with 'error' containing the error message
• If there is no 'jsonp' parameter, or it is empty, the webservice must return an HTML document, where the BODY of the document is the payload

It is also acceptable, though not encouraged, to return only a string with the payload rather than a dictionary. It is OK to return other values with the dictionary, excepting that all single letter keys are reserved.

How do I include JAHAH in my document?

You are free to do this anyway you like if you don't care for what we've done here. However, we do provide some pretty nifty tools if you want to try them. Note that do not add the 'jsonp' parameter to URIs here -- our code provides this function automatically to callback to the correct places.

NOTE: our JAHAH tools use MochiKit. We include a copy in our little source distribution for now, but we may take it out if this thing starts rolling.

Automatically load by magically marked likes

<script type="text/javascript" src="jahah.js"></script>
...

<a rel="jahah-include" href="http://www.example.com/jhah-service/">loading...</a>

Load a JAHAH document into a element (by ID)

<script type="text/javascript">
loadJSONDoc("http://www.example.com/jhah-service/", "element-id")
</script>

Show me something

Demos 3, 4 and 5 are the best

• Demo 1 — call document.write to synchronously load a document
• Demo 2 — call loadJSONDoc asychronously load a JAHAH document
• Demo 3 — include three different documents using rel="jahah-incldue"
• Demo 4 — include a RSS feed in a document
• Demo 5 — chose a URI an watch it get included

What JAHAH web services are available?

Our web services include a little form interface so you can play around with them. Remember that if you don't place something in the 'jsonp' parameter, a HTML document will be returned.

• jahah-include — extract the body or a fragment of another document and return it as a JAHAH document
• jahah-feed — convert an RSS/Atom feed into a JAHAH document. This needs some presentation options added, such as to return the doc XOXO microformatted.

Where can I get the source?

http://www.blogmatrix.com/tools/src/

Problems?

• Errors in loading the JAHAH document are not handled at all. This is very very bad. It's a matter of trapping 'document.onerror' and doing something with it
• Post-loading of content is imcompatable with Greasemonkey, which means tools such as microformat-action do not work.
• Mashing documents means that microformatted content cannot be directly recognized. HOWEVER, since all JAHAH documents are available as HTML documents (just omit the 'jsonp' parameter), we could add rel="jahah-include hatom xfolk" to indicate that there's 'hatom' and 'xfolk' content at the other side of the link.
• We're not in the business of providing a webservice so others can take other's content. At some point 'jahah-include' will block strange referrers
• 'jahah-include' does not rewrite URIs and thus links and images are often broken. We're going to fix this

So here’s my latest mini project, which I’m hoping is going to change the world and suck a max of 8 hours out of my time:

JAHAH—AHAH/HTML transported as a JSON(P) string.

Benefits:

• cross site scripting, as per On-Demand Javascript (not available in AHAH)
• data is basically HTML so it’s easy construct and consume, as per AHAH (not so with JSON)
• flexible end-use, as per JSONP

It would be nice if Javascript provided a way to “vet” the return results of script inclusions for security reasons, but we’ll do without. There will also be some unique considerations for microformats and Greasemonkey; we’ll cross that bridge when we get to it.

I’m trying to hack a demo together with MochiKit today to show the power of this idea.

Tagged: ajax, ahah, json, jsonp, web2.0, jahah, microformats.

One of the promises of Web 2.0 is the ability to combine pieces of different websites together to create new innovative products. A simple example (and one of my favorites) is The Ontario Beer Hunter, which combines Google Maps with data culled from the LCBO (and other) web sites^*. Take a second to look at that: it’s pretty cool.

The Beer Hunter accomplishes this task by letting Google do all the heavy lifting. I’m not just talking about the dynamic and interactive map generation. The site includes a script hosted somewhere on Google that does most of the HTML work. Do a view source and see for yourself.

To a large degree, the ability to create “mash ups” is been hobbled by important security concerns. This is not to minimize those concerns: if these security concerns were not there and with the correct clever scripting, script kiddies could potentially cull all sorts of useful information from your webpages.

Almost all ways of downloading data from other sites, IFRAME and XMLHttpRequest in particular, restrict the browser from either getting data from another site (i.e. different than the web page you are viewing) altogether or stop you from examining the data once you have it.

Fortunately, there is one method left: dynamically creating a SCRIPT tag in the DOM and executing it. This has been called On-Demand Javascript (why there’s no cute acronym is a mystery). Combined with Bob Ippolito‘s incremental improvement to JSON called JSONP (JSON with Padding), one can asynchronously call a web service running a different host, get a result and process it.

Unfortunately, there’s still a few security concerns but we’ve come a long way to creating mash ups.

^* If the LCBO used hCard to describe its locations and there was a microformat for describing store opening hours, “bad math” would have had a lot easier time writing this project. My first (failed) dot-com was a company called “onamap.com” that was planning to provide this type of service in 2000. The business plan is still good fun reading.

Tagged: ajax, ahah, json.

AJAX is the technology that makes Google Maps and Google Mail so cool. The “big trick” is that instead of reloading your web page to display a change (as we’re all used to), AJAX “behind the scenes”—without user prompting or action—loads the part of the page it needs and dynamically updates what you are seeing.

Typically, AJAX transfers the web page changes in a data format called XML. XML is nasty.

AHAH attempts to make it easier for developers to write AJAX applications by transfering HTML and just displaying that directly. HTML is the language used to write web pages (do “View > Source” in your browser) and is fairly easy to write and definitely easy to insert into an existing page.

However, HTML is not structured data and sometimes we want to work with that.

JSON stands for “javascript object notation”. JSON is the cat’s ass; IMHO by WAG it’s one of the most important pieces of web technology to appear in years^*. If you’ve worked with scripting languages, such as Python, Ruby, Perl and so forth, you have an intuitve sense of what JSON is all about.

Javascript is the (computer) language that every browser understands how to run. Javascript is kind of nasty, especially when combined with HTML, but lots of great libraries exist to make it easy to work with.
^* Nothing under the Sun is new but naming a concept gives it power. AJAX kind of existed before someone named it, but so what?

Tagged: ajax, ahah, json.