Good critique of the Google Contacts API over on Snellspace:

… as is typical of GData, all of the application specific data is contained in extension elements. While this is technically not a bad thing, it does mean that Google has effectively invented Yet Another Way of representing contact information. We already have vCard and hCard, both of which have been extremely effective and have a ton of existing application support. However, none of that existing code can be used with GData contacts. I understand why Google is using the extension elements but I disagree that the tradeoff is worth it.

Using extension elements basically means that “dumb clients” — Atom clients that do not understand the GData API, will not be able to do anything at all with the feed. There’s not even any displayable content that a human can use to extract information. Clients have to be written specifically against the GData API. Assuming that Microsoft also puts together a Contacts API, and assuming they also use extension elements to represent the data, client implementors end up having to write vendor specific code that does exactly the same thing. That’s bad.

Lotus, on the other hand, uses the hCard microformat in the payload, allowing standardized parsing and useful rendering even by downlevel clients.

The entry itself is generally just an envelope for an hCard and a linked vCard. Because the content element contains XHTML, dumb clients can render the feed content regardless of the fact that our hCard uses a number of Profiles-specific fields; and the linked vCard makes it significantly easier to integrate this feed with existing contact management systems. For instance, we have one customer who has used the Profiles feed to integrate directly into mobile device contact databases using the vcard links.

The main advantage the Profiles approach has over GData Contacts is that client applications do not have to write Profiles-specific code to integrate and interoperate. If the client understands Atom, XHTML, hCard and vCard, they can use the feed.

Standards are a good thing.

Libxml-Ruby is a blindingly fast way to parse XML in Ruby. However, many have complained that the interface is verbose and not especially Rubyish, and that the documentation lacks details and examples.

Thanks to the flexibility of Ruby, it’s easy to remedy this situation.

libxml_helper.rb, described here, opens up the XML::Node class from Libxml and adds helper functions that make it easier to use. The helpers also make it easier to use xpath with nodes that include default namespaces. (I intend to continue adding to the helpers to smooth rough edges as I encounter them.)

The interface was inspired by the fantastic HPricot, a “fast and delightful HTML parser”, and many HPricot examples will work unmodified.

Convenience functions

You can call to_xml_doc on any string to convert it into an XML::Document:

>> s = '<foo><author>p. bogle</author><bar>content</bar><bar>cont2</bar></foo>'
>> root = s.to_xml_doc.root

The at() method returns the first Node matching the given xpath:

>> root.at("author")
=> <author>p. bogle</author>

The search() method returns a list of Nodes matching the given xpath:

>> root.search("bar")
=> [<bar>content</bar>, <bar>content2</bar>]

search() can also be called with a block to iterate through each of the matching nodes:

>>  root.search("bar") do |bar| puts bar.xpath; end
/foo/bar[1]
/foo/bar[2]

The helper also improves the handling of default namespaces…

Read More