Slashdot Mirror

I'm not surprised, because it is eminently clear that Google wants to concentrate their social features on Plus (in effect, to compete with Facebook by cloning Facebook), but I am still disappointed.
I genuinely like Buzz; it aggregates activity from a whole range of services that I don't care to deal with (personal blogs, google reader, twitter, tumblr, etc.) for easy reading, instead of being another one of those services (Hi Plus!). It was even better because it used an open standard mechanism for identity management to do what it did.
Apparently the APIs for re-posting into Plus from external sites are starting to come together, so I guess that is the migration plan, even though it isn't as open or convenient. It would be nice if Google would set up rel=me peering behavior for plus to replace the functionality.

I'd really like to see a microformat for reviews take off. It could start in parallel to existing link-counting schemes so we just need a critical mass implementing it. Counting links is easy for search engines but we could get much better information by saying what we mean instead of just a link, possibly with nofollow.

There is hReview but it's in really bad shape. There isn't any agreement on nomenclature for the reviews -- no scales or weighting schema, or any way to communicate a rating schema. Anyone know of better or more common microformats for reviews?

RDFa is still around, there are a few sites that still use it, but my Firefox add-ons that would pull semantic data .from RDFa statements embedded in HTML are obsolete and gathering dust. Instead a lot of people put microformats into their HTML, especially hCard, because it's more HTML-like and less verbose. Google's Rich Snippets (starred reviews, etc.) will parse either form of structured data markup, but supposedly 94% of the info they parse is in microformat not RDFa. HTML5/WHATWG has a concept called microdata that seems to allow indicating the scope of microformat information, AIUI using new itemscope and itemprop attributes rather than overloading class attributes. But that seems to have no support for RDFa.

Google could parse a lot more structured data so we could tell them what the hell our web pages are about. I'm convinced the reason they don't do this is the most diligent users of ANY and ALL such techniques will be spammers and SEO bastards. This comment is really is about person:Angelina Jolie body_part:breasts last_updated:today!, despite all its links to cheap inkjet cartridges and online betting.

I got it from the actual url on the page in question. Beter ask the person who wrote the page, not me.

It's a content-encoding option. The file itself is transparently compressed if the client supports it. That means if you save it with wget, either wget will send an "accept-encoding" header and decompress it silently for you, or it won't send that header and it'll get the uncompressed version.

Here, try it yourself. It comes out to about 24k, when supported.

Very naive statement there,especially since the url, if you read my original post, is NOT the one you reference.

First, you don't give a URL in your original post.

Second, how is it naive? Watch this:

$ curl -s http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js | md5sum
10092eee563dec2dca82b77d2cf5a1ae -
$ curl -s http://code.jquery.com/jquery-1.4.2.min.js | md5sum
10092eee563dec2dca82b77d2cf5a1ae -

Well, surprise surprise, they match perfectly, unless you're seriously going to claim Google is exploiting an MD5 collision -- not impossible, but seems absurdly unlikely. Again, how is it naive to assume that when I ask Google's API for jQuery 1.4, I get jQuery 1.4?

And also totally irrelevant to the original point - a PROPER demo to support the claim that there are no other dependencies would NOT make reference to any other scripts.

Oh, I see. There was that claim. Fair enough.

Of course, as others have pointed out, it's not terribly difficult to remove that dependency, as it seems to only be using it for the load.

HTML != XHTML. Get over it, and stop making "fake" xml

Erm, no, that's real XML. Making it XML enables much easier access to microformats, among other things, and generally easier access from REST clients. It also means that, so long as the document actually is XML, the browser can use an XML parser instead of a raw HTML parser -- and XML parsers are much smaller and faster than HTML parsers.

Putting script tags anywhere else in the document is generally considered bad form because of the existence of document.write. The fact that it exists, even if you don't use it, means that the HTML parser has to completely stop and evaluate the script before it can continue parsing the rest of the document. It's in the head for the same reason you want to put the Content-Type meta tag near the top of the document -- as soon as your browser sees that Content-Type, it has to throw away any parsing its done and re-parse the entire document using the new encoding.

In other words, it's not just a matter of people whining about standards, it's a matter of making the best, fastest pages you can.

It's also not like you have to type more in order to do that -- that's what Haml is for.

You hit the nail on the head with "theoretically". We now have such joys as presentation through JS and semantics through CSS. Will the madness never end?

It is ironic that HTML, originally developed precisely to make it easy to mark up academic and technical information for publication, has never moved beyond the extremely bare-bones specification of heading, list, term, and paragraph tags. I would have expected some elaboration over time, but HTML seems frozen in time.

What happened, I think, is that people basically ignored HTML and went straight for word processing, a far more complex beast from a specifications point of view. For the past 20 years, we have been letting HTML languish while we attempt to come up with a document specification. ODF is the just the most recent cycle on this effort.

It is unfair of the parent to pin the blame for this on Microsoft, however. Word processing was one of the "killer apps" at the time of the birth of the web, and Word was just a niche player at the time. No, we went straight for the jugular of word processing because we all wanted to print to paper.

The OP is absolutely correct to think about revisiting HTML as a specification. What I hate about all reader-dependent formats (DOC, ODF, PDF, ...) is they force the user to completely leave the context of the web page just to view some data. The browser is the only "reader" I should need . If you can't at least embed on the page, fuggetaboutit. The gold standard is compound content with full document flow. Why oh why can't we come up with a simple way to blend content without drawing frames and putting scrollbars within scrollbars!?

Personally, I'd love to see some formality and general adoption of richer semantic markups such as the microformats hCard, hCalendar, etc. I'd also love to see some richer hierarchical markup; simple lists only take you so far! I'm imagining something with the hierarchy of XML but without the complexity of full extensibility, and all the definitional parts of a specification needed to support that (schemas).

The Atom Publishing Protocol is the perfect example of what I'm talking about: extensible, but easy to use because it comes with a well-chosen set of standard elements and attributes.

Remember the good old days, when transparency in government could be safely considered a good thing?

Generally, I'm still for it. Absolutely we need transparency in our government, and anything that brings us closer to point-and-click convenience over what we have now (FOIA requests left behind the radiator for 9–18 months to age and mellow) is for the best.

Furthermore, an open, accessible standard (i.e. no copyrighted DTDs, and I'm looking at you, Microsoft) will allow government resources to be brought together in interesting and inspiring ways. You know all those Facebook apps and Google Maps mashups? Imagine those applied to governance. The idea behind them is to put information together in new and interesting ways. If not only those in government, but the citizenry, can create government hacks like that, there would be great benefit.

Now let's talk hazards.

When was the last time you published your name and address online? See any good uses of microformats on any major sites lately? That's because there are some people on the Internet who are <sarcasm class="churchlady">not so nice</sarcasm>, and might willingly abuse whatever information they can find. The "government hack" alluded to above is an invitation to abuse. And we really can't afford to put government in that kind of position.

Another consideration, and I've stated this before, is that a wide line must be maintained between security and transparency. Security means that everything that must be kept secret is really kept secret. Transparency means that everything that doesn't have to be secure is made available somehow. If things aren't secured, the government becomes ineffectual and even detrimental. If things aren't kept transparent, the government itself can become abusive. A freely searchable infrastructure would make the transparency all that much more powerful, and make any breaches in security that much more severe.

It's only a threat if you think the Internet should stay in the same configuration it was in in 1983, when a 1200 baud connection was considered fast

This isn't about the technology, not directly. There are two points to keep in mind here:

First, Flash is proprietary. Making the Internet depend on proprietary technology is destroying the one thing that makes the Internet great -- anyone can connect, from anything.

That is: The Internet thrives on open standards. Flash isn't open, and Silverlight is neither. (Yeah, I know about Moonlight -- how long till that gets hit with patents from Microsoft, though, if it starts to matter?)

Second: Flash is its own little ecosystem. HTML really is very powerful -- done right, it's possible to both style it up very richly with CSS, and yet keep the HTML itself so clean that it's machine readable -- so much so that people start to build microformats on top of it. Makes the job much easier for screenreaders, also, or for people who want to reskin the page (just load up a Greasemonkey script and add a stylesheet).

Flash supports none of these things. There is some mention of accessibility, yes, but it's nowhere near where HTML is.

HTML separates things into pages and sub-page anchors. It's possible to do this with Flash, but only by piggybacking on top of what HTML is already doing, and with a fair amount of Javascript.

That is: I can bookmark this comment, if I need to. I can link to it from another page, directly. If Slashdot was written in Flash, would I be able to?

I could go on. And on.

The only legitimate use of Flash is to add functionality which isn't yet in a browser, and to select chunks of the page -- that is, YouTube isn't entirely Flash, just the player. But that should only be a holdover until the necessary things are implemented in the browser.

Considering the level of citizen journalism that sites like YouTube and LiveLeak have enabled, all thanks to Flash...

No, thanks to embedded video, which existed long before Flash, and is finally being done in a standard way with the HTML5 video tag. YouTube never needed Flash, and still doesn't.

Again, as noted further on in this thread: you might want to raise that complaint with Microformats.org in general, and David Janes in particular. Janes invented the hAtom microformat, around which WebSlices is based.

To be honest, though, I don't see how hAtom muddies the feed-standard waters any more than they were previously. It's intended to address a different problem space than RSS and Atom, so it's not really competing with either. The RSS/Atom issue, by contrast, arose from the introduction of competing standards to address the very same problem.

A more interesting issue is raised by Janes himself in the blog post linked above, namely Microsoft's decision to implement only a subset of hAtom as WebSlices, with their own top-level element to distinguish WebSlices from general hAtom feeds. I hope he makes his suggestions known to Microsoft, on this count, and I hope they listen.

Again, as noted further on in this thread: you might want to raise that complaint with Microformats.org in general, and David Janes in particular. Janes invented the hAtom microformat, around which WebSlices is based.

To be honest, though, I don't see how hAtom muddies the feed-standard waters any more than they were previously. It's intended to address a different problem space than RSS and Atom, so it's not really competing with either. The RSS/Atom issue, by contrast, arose from the introduction of competing standards to address the very same problem.

A more interesting issue is raised by Janes himself in the blog post linked above, namely Microsoft's decision to implement only a subset of hAtom as WebSlices, with their own top-level element to distinguish WebSlices from general hAtom feeds. I hope he makes his suggestions known to Microsoft, on this count, and I hope they listen.

Take it up with the Microformats folks. WebSlices are just an extension (and a fairly minor one) of the hAtom microformat. Most of your objections to WebSlices could be applied to microformats in general, or to any framework (jQuery, for instance) that uses class attributes for non-CSS semantic purposes.

About the only difference I see here is that the browser itself knows to take advantage of a microformat, and hopefully it's smart enough not to generate false positives from CSS classes with the same name. I can quickly think of a couple of easy ways to make that determination: namely, 1) look for the other required elements of the microformat ("entry-title", "entry-content", etc.), and 2) look for a CSS definition matching the class name. If the the other required elements don't exist in the correct relationship to the matched class, and a CSS rule with the same name exists, it probably wasn't intended as a WebSlice. That seems simple enough, and reasonably bulletproof — and if I could come up with it that easily, I wouldn't be surprised if someone on the IE8 team did as well.

Take it up with the Microformats folks. WebSlices are just an extension (and a fairly minor one) of the hAtom microformat. Most of your objections to WebSlices could be applied to microformats in general, or to any framework (jQuery, for instance) that uses class attributes for non-CSS semantic purposes.

About the only difference I see here is that the browser itself knows to take advantage of a microformat, and hopefully it's smart enough not to generate false positives from CSS classes with the same name. I can quickly think of a couple of easy ways to make that determination: namely, 1) look for the other required elements of the microformat ("entry-title", "entry-content", etc.), and 2) look for a CSS definition matching the class name. If the the other required elements don't exist in the correct relationship to the matched class, and a CSS rule with the same name exists, it probably wasn't intended as a WebSlice. That seems simple enough, and reasonably bulletproof — and if I could come up with it that easily, I wouldn't be surprised if someone on the IE8 team did as well.

<div class="hReview" moderation_status="insightful" rating="5"> Yeah, semantic web rocks. </div>

<div class="hReview" moderation_status="insightful" rating="5"> Yeah, semantic web rocks. </div>

Actually, I think you're confusing the semantic content of the element (the former says 'This is a division of a page in the article class', the latter says 'This is an article') with the actual intended content of the element. This is really of particular interest to Semantic Web and RSS technologies, as it gives an actual semantic context to the content inside the element, rather than an implied one that is dependent on human-interpretation to understand.

The idea of HTML+CSS was to separate semantic markup from styling markup. HTML5 doesn't change this fact. What it does change is the underlying semantic INTERPRETATION of the content. In particular, one example will prove the usefulness of an article tag (ignoring, just for a moment, the equal validity of RSS to solve it):

It is a given that more and more internet denizens reside in many different countries speaking many different languages. HTML already exists to support all of these languages, and what's to stop a Spanish developer from using

<div class="articulo">

instead of what you mention? The inherent meaning is the same, but to English speakers, and to the browser itself, it's now just a "subdivision of the page of class 'articulo'" which, strictly within the context of English, means absolutely nothing. The <article> tag, in contrast, actually imparts a semantic meaning to the content that is invariant by language, and is the same worldwide. Unless you support setting aside specific classes to impart to them specific semantic content (e.g. Microformats) which will almost certainly NEVER be able to be standardized to the point that it becomes a W3C standard (and thus practically a prerequisite to implementing a standards-compliant browser), the semantic content that HTML5 provides renders it a useful, if not necessary, change.

TLDR: HTML5 isn't about new ways to style, it's about additional semantic markup.

Reductio ad Absurdum: Why keep the <p> tag? It could just as easily be marked up with <div class="paragraph">, by your interpretation of HTML semantics.

If you are interested in real solution to semantic web markup that works (and is being used) right now, you might want to check out the Microformats website. There is a growing following that is working on getting the semantic web working properly. The Firefox and Songbird guys are looking at using Microformats to make browsing the web a much richer experience - NOW, not 10 years from now.

There are currently Microformats for marking up people, places, events, geographic locations, music, and many other widely used data items on the web. For more information on what Microformats are, check out the info page on Microformats.

If you are interested in real solution to semantic web markup that works (and is being used) right now, you might want to check out the Microformats website. There is a growing following that is working on getting the semantic web working properly. The Firefox and Songbird guys are looking at using Microformats to make browsing the web a much richer experience - NOW, not 10 years from now.

There are currently Microformats for marking up people, places, events, geographic locations, music, and many other widely used data items on the web. For more information on what Microformats are, check out the info page on Microformats.

META keywords provides keywords for a page.

The better, more relevant standard for tagging is the rel-tag microformat, http://microformats.org/wiki/rel-tag

You put a rel="tag" attribute on a hyperlink to the page on Del.icio.us or whatever that defines the tag. The microformats.org page succinctly explains the benefits of this approach.

It even explains how to encode spaces and special characters. So there's NO issue with the envelope or format, except that Del.icio.us (or is it Technorati?) doesn't like spaces in tag names.

As for the *content* of tags, yeah they're unavoidably a disorganized mess. Eggheads who know about ontology and RDF say they can't work. But they do, sort-of.

--
=S

The rel-tag microformat is an attempt to standardise tagging. It relies on other microformats to define what it is you are tagging. There isn't a 'photo' microformat at the moment, so you can't do a web-wide search for photos tagged 'fireworks' for example. If you're interested in the semantic web it's worth checking out microformats. You can download a plugin for firefox that reads microformats. Go and have a look at Flickr with it, or any other site that implements microformats. If people have tagged something with a 'geo' tag giving long. and lat. then it will bring up a Google Map showing the location. If they've included a 'hCard' around their contact details you can add it to your address book.

If you want true separation, use XML for the data, and XSLT to transform it into HTML.

That's what I used to do too, until I read Zeldman. I loved it. One of the big disadvantages, however, is that you lose the semantics of HTML (such as they are). Those semantics are valuable - for search engines (clean HTML can make a big difference) and for other applications. There aren't a lot of data formats as well-understood and universal as HTML; that's worth taking advantage of. Remember, your HTML is likely to outlast whatever data source you're pulling your content from.

These days I depend on those semantics. I've been doing DOM work with Javascript to add dynamic annotation with margin notes and highlighting to web pages. I need to know the content model so I can determine where I can insert tags to add highlighting (<em> can go in <p> but not in <style>, for example). I locate highlights by counting words, so I need to know where words break. Block-level elements break words, while inline elements don't (so in your example you need a minimum of div, a, and span). I also collect other metadata, like the title and author of the annotated content, and so on. I do that by looking for elements in the document tagged with specific microformat classes.

What are the benefits? Well, if you look at my code, the output of my Javascript or my Atom feed, the information is all meaningful in a standard way. This can reduce or simplify glue code if you need to work with my data - and I think the universal experience with glue code is that although it seems simple and brainless, it gets heavier and heavier until it places serious limits on application complexity. Over time, I hope this kind of standardization can slowly lead to apps and libraries being easier to plug together. The standardization of HTML, and the shared meaning of some of its elements has already proved a huge win on the Web, messy, inconsistent, and broken as it is.

But I'm a geek of simple pleasures. Right now, I'm just thrilled that my transport format I picked - Atom (with embedded HTML) - is machine readable and shows up with sensible formatting in a generic feed reader. (I couldn't afford to use HTML if were a layout language, because then changing the look would break my machine parsing.) It's not rocket science - but that's kind of the point.

That feature is seriously screwed up. Microsoft are *still* trying to sell people on the idea that its ok to share around the editable document, when in reality its hardly ever ok. All it takes is for one person to forget to remove hidden data and you're on the news.

Look at the list of Office products it integrates with - there's one missing. Outlook. Why isn't outlook set up to prompt you to ask if it should strip the documents before sending? Why is there no feature on exchange to block emails leaving the domain with unstripped attachments? Why doesn't iis block access to unstripped files? Now those would make it a feature worth having.

Stepping back from MS for a moment, the same problem actually exists in many other file types - even html (meta tags and comments). Its why the microformats movement thinks metadata should be presentable and parsable rather than hidden in 'document properties'. Their solution isn't complete though - we need to separate the notions of 'Save As' and 'Publish'. One way to achieve this in a corporate/government environment would be for servers to require digital signatures on outgoing documents - this would introduce publication into a document lifecycle for the purpose of integrity, at which point we can hook in 'strip doc' wizards to minimize risk.

Just thinking out loud.

While your analysis of the e-mail is astute, I think you missed Zeldman's larger point, that this e-mail is just one piece of evidence in growing frustration amongst rank-and-file web developers with the W3C. Other developers have agreed.

I used to be a member of some W3C mailing lists, but got frustrated by the lack of momentum. Most of the e-mails were deflected as, "someone has already proposed that, read the archives!" or "that is not implementable." Constrast that to WHATWG, where my comment on a spec not granted me a reply from that spec's author, but also gave me a bit of enlightenment into the process.

I was a flag carrier, a proselytizer. Now I just read mozillazine and the Opera blog to see what's coming. It does seem to me that lately all the W3C is good at moving on is publishing standards other people wrote.

The full semantic web scheme really ignores a lot of what the Internet has taught us about what technologies succeed. It's not about grand visions and long specifications, it's about simple stuff that solves real problems of limited scope. Look at RSS, for instance; it's about the simplest thing which could do the job it does.

I think we'll eventually realize most of the benefits of the semantic web, but it won't be a result of a grand vision imposed from the top down and implemented all at once. It'll probably be though increasing adoption of microformats, which don't try to classify and specify everything, and are implemented entirely using existing web standards.

exactly! sure the idea of using css class names to represent something for a machine to read is not new as it is an obvious one. I thought of it too when I first saw CSS used just like I thought of using made-up tags to represent things when I first saw html ... but THAT IS NOT THE POINT - - the STANDARDISATION, the fact that LOTS OF PEOPLE ARE ACTUALLY STARTING TO USE IT, and the SIMPLICITY is what makes microformats interesting - For someone like me who has been looking for many years for ways to make it easy for an events promoter to provide machine readable data for a nightlife listings website ( www.spraci.com ) without needing to provide them with special software and then having to teach them how to use it, its an exciting thing! Sure the preferred way to add an event is to use the forms on the site - but not all promoters have the time to do it and some may already have their events listed on their own sites - why should they have to enter the same data over and over to get it listed on a few listings sites? ... see the problem? You might ask "what about RSS?" .. think about it ... Events listings are calendar data - they need DATES ... plain old rss does not do that .... (unless you use extended versions like RSS+Event - but not much software out there uses that - so that inevitably means people need to modify their software - not much good for most event promoters!) spraci.com and many other listings sites require event dates to be seperate and machine-readable because people can look up events by date. "What about iCal?" Is there a way to represent cities/countries/etc in iCal? Listings sites that deal with more than one city need that kind of information. If you use hCalendar you can combine it with hCard to specify the city/country! For some of us who have been trying to get data syndication of this kind happening for years and having to deal with a lack of standards and software using them that is suitable for the average event promoter to use I see microformats as a very good thing. 1. they are easy for people to understand and use without needing to spend hours reading documentation to figure out the basics of what it does... a simple example is almost self-explanatory 2. not hard to parse with very basic xml/html/etc tools - you don't need anything exotic or overly bloated. 3. lots of people are actually already using it - that is pretty rapid uptake! (what use is a "standard" if nobody is using it?) 4. it is actally trying to addresses the real world situation in a real world way. - html is everywhere - people want to create and consume data feeds containing data not handled well by plain old rss - people also want to embed data in other places where they might be using html - people want the minimum of installing or modifying software to do it - they want it NOW with a minimum of fuss - there might be more than one item to be represented on one page (that pretty much rules out using meta) - it tries to work with other existing standards where possible (eg hCalendar is based on iCal / hCard is based on vCard) yes do check out http://microformats.org/wiki/ ...and if you are still not sure check out some of the links on there to other sites using microformats for more real-world examples.

In IBM's defense, it's not a format they've made up. hCalendar's primary author is from Technorati.

The VERY relevant site that Jack Herrington forgot to mention there is Pingerati. That is THE site through which all these Microformats are shared. The system is based on pings, much like the rest of the blogosphere. Both Pingerati and Microformats have a major force behind it - Technorati.

I think the problem that this comment and many others demonstrates is that many people can't get away from the idea that if something doesn't "boil the ocean" (that is, solve all possible problems as completely as possible for all people at all times) then it is useless.

Microformats, rather just being "blessed things you must use from people smarter than you", are an approach to the problem of how to we take emergent behavior on the web (such as the fact lots of people put reviews, or contact information, or information about their relationships with other people on their blogs and other sites) and create usable constructs which work on today's web, with today's browsers and today's tools, wth developers' current sets of skills, to enable software to more meaningfully aggregate this information, to enable much better web based data interchange, and to generally encourage decentralized services.

People are already doing very cool things wth microformats. Big organisations like Yaghoo! Less than 5 minutes at http://microformats.org/ ought to demonstrate that there is already significant adoption and mindshare, that f!=XML, lisp etc and it's probably better to understand a little before criticizing based on a short synposis of an article, but I forgot this was slashdot.

But seriously, check it out. No wifi. Not Lame. Will change web. You read it here first.

So I guess I have to ask again: How much of microformats could have been done using META, given that it's scoped to the page (which is no problem for the most important page semantics), and uses attributes?

Very little. For instance -- if I had a full page calendar display -- because META is scoped to the whole page, I couldn't include an event record for each individual event -- I'd have to have the person go to a 'more information' link, and then give the event information. If I wanted them to do that, I could've just given them an iCal file. This allows the semantic marking to be along side the format to be presented to the user. (as we would assume that the person wouldn't want to pull down all events from the calendar -- think something like registering for classes in college, where you might only want one or a few from the full list of events)

And many times, even when there is a single event mentioned within a document, it would not be semantically correct to say that the event applies to the entire page -- it may only be a section of the page that is relevent to the event. (eg, the front page of a website, with info about a company, and then an upcoming event announcement)

I personally didn't like the examples given in the IBM article. Some of the past examples that I've seen include embedding semantic detail within a paragraph of text (eg, a movie review), so that different review formats could then be processed in an automated way.

The article mentions the wiki, but doesn't link to it, except at the very bottom of the resources section.

Remember when XML was going to revolutionize communication between computers by structuring everything consistently?

No. I do remember how a lot of clueless PHB-types ran around telling everybody that though. XML solves the parsing problem, not the semantics problem. It's languages built on top of XML that handle semantics.

XML was never meant to solve the problem you are talking about. Parsing markup into a tree is a totally different concept to figuring out what the stuff in the tree means. The only people who ever thought XML had something to do with what you say were totally clueless about XML.

So now why is this "vevent" class special, and who decided it would be "vevent" and not "scheduledevent" or "calendarevent" or "microsoftcalendarhassomethingforyoutodotoday"?

It's special because it appears in the hCalendar specification. The people who wrote the specification decided it would be "vevent". They intend to submit it to a standards body.

1. Carefully pick your XML as a subformat of XHTML (preferably from existing microformats).
2. Use noscript tags and CSS-hidden hyperlinks to provide scriptless, synchronous access to your otherwise Ajax content (link directly to the microformat files).
3. Test the design with scripts off to be sure navigation to all content remains possible. If content becomes inaccessible, there's usually an easy way to link to it. If you don't want Ajax users to "see" a link, hide it with CSS or script the DOM to prune it from the tree.

If design allows, use the response handler of the XSLT doc to call the request for the XML data, to ensure XSLT is available when XML arrives. If that won't work (ie, when you need the same XSLT file for a variety of XML docs), have the XSLT handler set a flag to true when fully loaded, then wrap calls to dependent XML docs in functions that are called directly if the flag is true, but otherwise are diverted to a timeout/repeater/timed event that checks the flag each second or so (for a max number of seconds) until the XSLT doc is available. Most Ajax toolkits set up a kind of dependency array where you can queue pointers to the functions that are all waiting on the same condition, so that they get called in script order when the condition becomes true.

If that makes no sense, well, it's a little off-topic, so I probably shouldn't elaborate.

IMHO, XSLT is still not quite ready for prime time (doesn't work right in some of the major browsers) so do a sanity check in Firefox to see if it's your code that's messed up, or just a browser quirk. I have done lots of tests between XML+XSLT and subformats (XML subsets of XHTML based on microformats), and the subformats win hands down every time. For now, I'd advise holding off on client-side XSLT for at least another year. Subformats are full-fledged XML, they're just not quite as "semantic" as freeform XML can be.

I'm not sure if there's a standard microformat for slide presentations, but I use XOXO, a general-purpose hierarchical outine system that has a lot of support (including a WYSIWYG online editor script by Les Orchard). The way I'm using XOXO, scriptless browsers see a familiar bullet list with links to slides, then use the back button to return to the list if they can't handle framesets. Ajax browsers get treated to a full-featured slideshow with cross-fading, simple animations, and an optional hierarchical floating menu to skip to any slide (same XOXO file with different CSS). With the right CSS and JS, the same XOXO-based list can auto-adapt to the client.

I won't be adding the article's version of automatic pan-and-zoom (Ken Burns effect) because it's a little too inflexible and rudimentary. All my project's missing is a flag and a randomizer, so no need for a new approach. The article might be a decent academic tutorial for students unfamiliar with XHR. However, I wouldn't suggest using the article's ideas in any production work, as many better options are readily available.

I really suggest you take a look at the microformats site to see some examples of how semantic annoatations are being worked into existing standards.

The REL attribute has a set list of link types to be associated with it.

Did you read that page you just linked to? If you keep reading further down, you'll find that this is not an exclusive list; you can put whatever you want in there. From the specification:

Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details.

It's true that Google don't force you to use a profile, but there's nothing stopping you from using an appropriate profile anyway. Google aren't doing anything that isn't explicitly permitted by the HTML 4.01 specification.

They could have done this already with their main index using normal HTML and microformats. Yet it seems Google aren't very keen on HTML at all. They don't write valid HTML for their websites, they don't use standard HTML links in GMail (making it impossible to, say, open an email in a new tab), they ignore HTML semantics when spidering websites (e.g. you can rank keywords appearing within <h1> elements as relatively more important than the rest of the page).

It's true that HTML offers relatively little semantic information compared with domain-specific formats. However it does offer some useful information, and since HTML is a very flexible and extensible format, a hell of a lot more can be added with microformats, while staying compatible with all the other HTML software already in use. Why don't Google work with current formats instead of splitting things off this way?

Dean then started to talk about the power of the enclosure element in RSS 2.0. What is great about it is that it enables one to syndicate all sorts of digital content. One can syndicate video, music, calendar events, contacts, photos and so on using RSS due to the flexibility of enclosures.

Amar then showed a demo using Outlook 2003 and an RSS feed of the Gnomedex schedule he had created. The RSS feed had an item for each event on the schedule and each item had an iCalendar file as an enclosure. Amar had written a 200 line C# program that subscribed to this feed then inserted the events into his Outlook calendar so he could overlay his personal schedule with the Gnomedex schedule. The point of this demo was to show that RSS isn't just for aggregators subscribing to blogs and news sites.