Archive for December, 2004

The Danger of Losing Context with XFN

Friday, December 31st, 2004

As I re-posted Robert Scoble’s geek dinner attendance list, I noticed that he included XFN notation in the links. When I re-posted the links, I made sure to edit all of the rel attributes to reflect my own relationships. But I could imagine that someone who uses a tool to copy links or simply is not yet aware of XFN might copy and paste them without realizing that s/he was specifying accidental semantic web relationships.

Those rel attributes convey one-way relationship information; from the owner of the containing page to the owner of the link. XFN tools must infer that the originator of the relationship is the owner of the page in which the link exists.

Since one half of the relationship is implied from the context of the containing document, there is a danger of misrepsenting relationship information by decontextualizing (re-posting) links that contain rel attributes. This problem would apply to any use of the XHTML rel attribute.

Maybe this won’t happen much, but I wonder if we can come up with something to help keep the XFN network from being corrupted by such decontextualization.

SF Geek Dinner

Friday, December 31st, 2004

Robert Scoble with Channel 9 schwag

The Geek Dinner at Chaat-am cafe, and after-party at Matt Mullenweg‘s last night was a quite a good time. As for the little people, they were all in order when I left.

I got to speak with Tantek more about the addition of tags (keywords) to the attention.xml draft. I especially like the fact that tags can be applied to both feeds as well as articles.

Renee Blodgett wrote a nice write up of the event, and so did Thomas Hawk.

The Geek Dinner Attendance List via Robert Scoble:
Robert Scoble | Steve Gillmor | Steve Sloan | Dori Smith | Farida Paramita | Michael Eakes | Dan Gould | Christopher Carfi | Masha Solorzano | Scott Rafer | Dan Farber | Lisa Canter | Marc Canter | Mimi Canter | Lucy Canter | Lyndon Wong | Ron Lichty | Tom Conrad | Marc Novakowski | Pierre Wolff | Nadeem Bitar | Kaliya Hamlin | Brian Hamlin | Ian Jones | Nicole Lee | Kevin Marks | Thomas Hawk | Neal Drumm | Tony Chang | Zack Rosen | Kieran Lal | Jasmeet Singh | Jason DeFillippo | Ian Kallen | Kevin Burton | Brad Neuberg | Renee Blodgett | Jeff Minard | Om Malik | June Parina | David Sifry | Jonas M Luster | Micah Alpern | eleanor kruszewski | Jim Grisanzio | Tantek Celik | Rebecca Eisenberg | Curtis Smolar | Russell Beattie

DHTML is Growing Up

Thursday, December 30th, 2004

Brad Neuberg recently spotted a programmer in a coffee shop hacking on a DHTML application. There have been quite a few DHTML sightings lately, making me believe that DHTML is finally coming of age.

Dynamic HTML is not a specific technology but rather a technique of creating rich internet applications by augmenting static HTML with client-side scripting and style definitions. In practice this is often done with HTML, JavaScript, and CSS.

There are various other frameworks for rich internet applications, such as Flex and Laszlo, but they have not gained popularity; perhaps this is because they rely on Flash as a 3rd party browser extension. Since DHTML relies only on Javascript and CSS, which are now both widely supported in modern browsers, DHTML should be clear for take off.

So what is the holdup? The biggest gotcha with using DHTML is having to wade through the qaugmire of browser incompatibilities in their support for Javascript and CSS. Javascript-based DOM methods in one browser might not have the same effect in another browser. Also, the lack of cross-browser CSS support creates a large amount of developer consternation.

Some folks are working to fix the mess. The open-source x library encapsulates all the DOM incompatibilities by creating a browser-independent javascript API for DOM manipulation. On the CSS front, Dean Edwards has taken the approach of “leveling the playing field”; his cheekily-named IE7 project is a complex layer that makes Internet Explorer behave in a CSS compliant way.

These kinds of grassroots efforts are typical with DHTML, because unlike Flex and Laszlo, DHTML has no standard libraries or toolkits. In fact, the community has been re-inventing DHTML tools for years without coming up a standard cross-browser DHTML solution.

Things have come a long way, however, and the frontiers are now being pushed with DHTML. Mihai Bazon of Dynarch, for example, has produced some really slick DHTML menus and other widgets; I even found myself right-clicking on them to convince myself that they were not actually coded in Flash.

DHTML seems to work best when applied lightly and transparently, avoiding the worries of rich internet applications. Some of the best uses of DHTML are when you don’t even realize that it is DHTML, such as Google’s GMail. I believe DHTML is least effective when used in an attempt to make a web application look like a desktop application.

With all these cool new techniques, DHTML can also bring a few annoying possibilities, such as DHTML pop-up ads. Many users have been switching to security conscious browsers and otherwise blocking ads that pop up in separate os-native windows, but DHTML pop-ups are a whole new way to get your attention. The first time I visited this Time Magazine story, I was barraged with two (annoying but harmless) DHTML pop-up ads.

As more DHTML libraries and widgets are released with open-source licenses, it seems more likely that DHTML will continue to gradually enrich web applications enough so that the adoption of a separate RIA framework like Flex or Laszlo might no longer be necessary.

Sink the Splash Pages

Wednesday, December 29th, 2004

The article Sink the Splash Pages from gives some good reasons to cut right to the chase:

Skip intro splash pages degrade performance, increase bailout rates, and decrease your search engine rankings. Most importantly splash screens reduce web credibility with up to 71% traffic loss.

I’ve been Rubhubbed!

Wednesday, December 29th, 2004

“That’s great! Actual physical contact! Can you move?”
“I feel so funky

Rubhub, the XFN Aggregator, finally indexed my XFN Friendly blog. Last month I wrote a post XHTML Friends Network. Inside that post, I included some links with xhtml rel attributes (with values from the XFN spec) to specify my outgoing relationship to various people. After that I visited rubhub and added my site to their aggregation list. Now, rubhub has indexed some of the relationships that I included in the post and in my blogroll. For some reason though, it only picked up 3 out of the 8 distinct links I had adorned with XFN rel attributes.

Representational State Transfer (REST)

Thursday, December 9th, 2004

REST (REpresentational State Transfer) describes an architecture style for networked systems. It also happens to be the underlying architectural model of the Web. Roy Fielding coined the term in his PhD dissertation.

The basic characteristics of a REST system are:

  1. Client (browser) and server
  2. Stateless Interactions
  3. Cacheable Resources (using Meta info)
  4. A uniform interface (HTTP)
  5. Named resources (URIs)
  6. Interconnected resource Representations (a href)

So, the web is already a RESTian system. The parenthetical information after each item in the above list shows how the current Web satisfies that design principle.

The idea of making a RESTian system is to see it as a data resource manipulation problem. To sum up the REST Best Practices from a presentation by Roger L. Costello:

  1. Expose a URI for each resource
  2. Use logical URIs (not physical)
  3. Use nouns in the URIs (not verbs)
  4. Use the / in URIs to represent parent/child relationship
  5. Minimize use of query strings
  6. use GET for resource representations (not POST)
  7. Make all HTTP GET requests side-effect free
  8. Include links in responses, gradually unfolding information.

Strong proponents of REST such as Mark Baker purport that it is a natural tendency for document oriented systems, because documents are in fact state.

From an article by Paul Prescod:

The best part about REST is that it frees you from waiting for standards like SOAP and WSDL to mature. You do not need them. You can do REST today, using W3C and IETF standards that range in age from 10 years (URIs) to 3 years (HTTP 1.1).

Use Tag Files For Modularity in JSP

Monday, December 6th, 2004

Have you ever come across JSP code peppered with <%@ include %> directives? Back when we were limited to JSP 1.1, include directives were a decent means to build modularity and re-use code. The biggest problem with the include directive, however, is that included code does not get its own stack. Variables used by the included fragment are the same variables used by the JSP that included it. For a large scale project, the complexity of documenting the inputs of fragments and the manual enforcement of those inputs become a burdon upon productivity. In practice, the include directives are a source of very difficult-to-track errors.

Don’t worry though, because you can use Tag files to address all of those issues. JSP 2.0 Tag files offer huge modularity advantages over include page fragments. Tag files are almost identical to regular JSP files, except they have the <%@ tag %> directive at the top instead of <%@ page %>. You will probably also want to make use of some <%@ attribute %> directives.

Use tag files when you need:

  • re-usable, modular JSP code
  • required attributes
  • attributes type checking
  • a stack (for recursion)

Here is a great step-by-step guide by Andrei Cioroianu that will take you through the process of converting included jsp fragments into .tag files.