update: 2008/04/08: added an all microformats option based on a suggestion from Assaf Arkin.
So Google published a Contacts API based on Gdata (in turn based Atom and Atompub). This particular Application Protocol Interface allows client applications to view and update user contact details and most Google services have access to the contact list.
Here's an example of a Google contact entry:
<atom:entry xmlns:atom='http://www.w3.org/2005/Atom'
xmlns:gd='http://schemas.google.com/g/2005'>
<id>
http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de
</id>
<updated>2008-03-05T12:36:38.835Z</updated>
<link rel='self' type='application/atom+xml'
href='http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de' />
<link rel='edit' type='application/atom+xml'
href='http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de/1204720598835000' />
<atom:category scheme='http://schemas.google.com/g/2005#kind'
term='http://schemas.google.com/contact/2008#contact' />
<atom:title type='text'>Elizabeth Bennet</atom:title>
<atom:content type='text'>Notes</atom:content>
<gd:email rel='http://schemas.google.com/g/2005#work'
address='liz@gmail.com' />
<gd:email rel='http://schemas.google.com/g/2005#home'
address='liz@example.org' />
<gd:phoneNumber rel='http://schemas.google.com/g/2005#work'
primary='true'>
(206)555-1212
</gd:phoneNumber>
<gd:phoneNumber rel='http://schemas.google.com/g/2005#home'>
(206)555-1213
</gd:phoneNumber>
<gd:im address='liz@gmail.com'
protocol='http://schemas.google.com/g/2005#GOOGLE_TALK'
rel='http://schemas.google.com/g/2005#home' />
<gd:postalAddress rel='http://schemas.google.com/g/2005#work'
primary='true'>
1600 Amphitheatre Pkwy Mountain View
</gd:postalAddress>
</atom:entry>
Grand. Lots of extension XML. You talk GData you're set. However aside from pulling this data around into address books, a really common case is just showing the user the info.
In that vein, here's the same data, using the hCard microformat embedded in the atom:content element instead of GData extensions:
<atom:entry xmlns:atom='http://www.w3.org/2005/Atom'
xmlns:gd='http://schemas.google.com/g/2005'>
<id>
http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de
</id>
<updated>2008-03-05T12:36:38.835Z</updated>
<link rel='self' type='application/atom+xml'
href='http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de' />
<link rel='edit' type='application/atom+xml'
href='http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de/1204720598835000' />
<atom:category scheme='http://schemas.google.com/g/2005#kind'
term='http://schemas.google.com/contact/2008#contact' />
<atom:title type='text'>Elizabeth Bennet</atom:title>
<atom:content type='xhtml'>
<div xmlns="http://www.w3.org/1999/xhtml">
<div class="vcard">
<a class="fn url"
href="http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de">
Elizabeth Bennet
</a>
<div class="adr">
<span class="type">Work</span>:
<div class="street-address">1600 Amphitheatre Pkwy Mountain View</div>
</div>
<div class="tel">
<span class="type">home</span>(206)555-1213
</div>
<div class="tel">
<span class="type">work</span> (206)555-1213
</div>
<div>Home Email:
<span class="email">liz@example.org</span>
</div>
<div>Work Email:
<span class="email">liz@gmail.com</span>
</div>
<div>Gtalk:
<a class="url" href="xmpp:liz@gmail.com">liz@gmail.com</a>
</div>
</div>
</div>
</atom:content>
</atom:entry>
It seems to me like Google could support a uF format option as a parameter flag.
There's more.
Windows Live
Here's a sample of the Windows Live Contacts API:
<?xml version="1.0" encoding="utf-8" ?>
<Contact>
<Comment>This is updated primary ABCH test account</Comment>
<Profiles>
<Personal>
<NameToFileAs>Updated ABCH Int</NameToFileAs>
<NameTitle>UpdatedMr.</NameTitle>
<FirstName>UpdatedAbch</FirstName>
<MiddleName>UpdatedPg</MiddleName>
<LastName>UpdatedInt</LastName>
<Suffix>UpdatedJr.</Suffix>
<YomiFirstName>UpdatedAibiceiachi</YomiFirstName>
<YomiLastName>UpdatedCeshiban</YomiLastName>
<Birthdate>1987-02-26</Birthdate>
<Anniversary>May 8th</Anniversary>
<Gender>Female</Gender>
<TimeZone>GmtMinus6h</TimeZone>
<SpouseName>UpdatedStorage</SpouseName>
</Personal>
<Professional>
<JobTitle>UpdatedSDE</JobTitle>
<Profession>Updatedaddress books</Profession>
<Manager>UpdatedWindowsLive</Manager>
<Assistant>UpdatedSomeone</Assistant>
</Professional>
</Profiles>
</Contact>
Which is a format more focused on the address domain - for starters it does not use Atom as a scaffold. I'm not going to try to convert that into hCard, but do note the "CamelCase" style markup; that's generally done to ease roundtripping in and out of OO languages (if you're a Java dev and have used XStream you'll have seen this in action).
xAL
Moving further along the domain specific line, here's an example of xAL, the eXtensible Address Language from OASIS.
<!-- 201/2288 Pine Street
Vancouver, BC
V6J 5G4
Canada -->
<AddressDetails>
<Country>
<CountryName>Canada</CountryName>
<Locality Type="State">
<LocalityName NameType="Abbreviation">BC</LocalityName>
<LocalityName NameType="Full Name">BRITISH COLUMBIA</LocalityName>
<DependentLocality Type="City">
<DependentLocalityName>Vancouver</DependentLocalityName>
<Thoroughfare Type="Street">
<ThoroughfareName>Pine Street</ThoroughfareName>
<Premise Type="Apartment Building">
<PremiseNumber>2288</PremiseNumber>
<SubPremise Type="Unit">
<SubPremiseNumber>201</SubPremiseNumber>
</SubPremise>
</Premise>
</Thoroughfare>
</DependentLocality>
<PostalCode>
<PostalCodeNumber>V6J 5G4</PostalCodeNumber>
</PostalCode>
</Locality>
</Country>
</AddressDetails>
Again more CamelCase markup, but the thing to note here is that the elements are not always carying the key information. There are Type attrributes that have the information your really want, such as "Type='Street'". xAL is in a sense a 'domain specific schema language'. It also has overly specific and/or localised elements like "ThoroughfareTrailingType". There's a lot to the xAL spec; what you see there is but a fragment. Incidently, the Irish government have a profile of it for eGovernment interchange.
Microformats all the way down
update: 2008/04/08. Assaf asked in a comment: "Why not go microformats all the way?" . It's an interesting idea. So here we go, using hAtom instead of Atom markup:
<div class="hentry entry" id="http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de">
<div class="updated">2008-03-05T12:36:38.835Z</div>
<ul class="links">
<li>
<a href="http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de"
title="self" rel="tag self">Permalink</a>
<a href="http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de/1204720598835000"
title="Edit" rel="tag">Edit</a>
</li>
</ul>
<ul class="categories">
<li>
<a href="http://schemas.google.com/g/2005#kind" title="Contact" rel="tag">http://schemas.google.com/contact/2008#contact</a>
</li>
</ul>
<h3 class="entry-title">Elizabeth Bennet</h3>
<div class="entry-content">
<div class="vcard">
<a class="fn url"
href="http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de">
Elizabeth Bennet
</a>
<div class="adr">
<span class="type">Work</span>:
<div class="street-address">1600 Amphitheatre Pkwy Mountain View</div>
</div>
<div class="tel">
<span class="type">home</span>(206)555-1213
</div>
<div class="tel">
<span class="type">work</span> (206)555-1213
</div>
<div>Home Email:
<span class="email">liz@example.org</span>
</div>
<div>Work Email:
<span class="email">liz@gmail.com</span>
</div>
<div>Gtalk:
<a class="url" href="xmpp:liz@gmail.com">liz@gmail.com</a>
</div>
</div>
</div>
</div>
</div>
Looking at it, I'm not convinced. Things like links and categories don't seem to map on well. We've also lost the ability to hook into the syndication tool chain- socially, architecturally, or whatever way you want to put it, that's a big loss. [I think if XHTML could support a web of syndication, we'd already be using it for that.] Personally speaking, I find hAtom one of the harder microformats to understand, certainly compared to hCard. So to me Atom carrying a microformat is still the right tradeoff.
CardDAV
CardDAV as found in draft-daboo-carddav-04.txt. Allow me to echo Mark Nottingham's sentiments and skip the example - I don't get it. Granted, it's based on vCard as hCard is (and the others are not). But still, I can't see CardDAV getting traction.
10 Comments
I can't make head nor tail of the Google contact entry. It's not even valid xml.
A pre tag seems to have snuck in at the end there--it's making the last paragraph very wide.
"the Google contact entry. It's not even valid xml."
"A pre tag seems to have snuck in at the end there--"
Fixed. Thanks!
"Best the most readable option I could think of would be hCard inside hAtom. "
Assaf, I added an example. I'm not convinced hAtom gives anything - it might even lose small amounts of information, and it certainly takes away the syndication chain.
"xAL looks like there's a 500 page spec with a meta-meta model you need to read before you're allowed in the club."
That's about the size of it.
"hAtom is actionable."
"Atom is not actionable"
The Atom+hCard example I gave breaks apart nicely. I'm just not seeing the distinction.
"It should be possible to add Atom support to all the applications that currently only deal with HTML. And it should be possible to add hAtom support in feed readers."
Right.
"Atom and hCard is a hybrid, so I'm either using the wrong toolset, or context switching between two different representation models"
We use Atom to carry (X)HTML all the time; two models works fine there. XSLT can bridge the two easily enough.
How do you handle publishing and updating of address data using hcard? This is one issue I've had a hard time dealing with. There doesn't appear to be a way to provide an introspection method to specify in either an atompub workspace document or an atom entry itself that only valid xhtml hcard can be put or posted to the server. Is the solution to only accept vcard itself? This would seem somewhat limiting and non-ideal.
"update: 2008/04/08" Hey, where do you live? It's only March in Sweden! :-)
Cheers,
David (http://www.divideandconquer.se/)
Actionable? I don't need any more actions damnit, give me something an agent can work with on my behalf :-)
Lacking from the list is Atom with RDF payload, a nice combination imho as the Atom wrapper can deal with updates, the content easy to integrate with other data. Although RDF/XML using the vCard vocab would be one approach, most of the examples you give could be isomorphic (and XSLTable) assuming you could reliably tell that the content was an encoded card.
On that fron the GData example seems to fare better than the microformats one - while the atom:category looks a bit hacky, at least it's URI-based, you don't have to go sniffing for special strings. What lets it down is that the URI 404s, which detracts somewhat from the follow-your-nose way the web works...
http://www.w3.org/DesignIssues/diagra...
see also: Beatnik address book -
http://blogs.sun.com/bblfish/entry/be...
Assaf, you lost me at "Web browser" :-)
We all know browsers accept XHTML (that's half the reason to use uF over a dedicated XML). Bu the fact we can cut and paste in and out of browsers still doesn't remove the need for Atom to exist.
And Dave's point is a good one - "How do you handle publishing and updating of address data using hcard?" , or in general, how to use uF to drive editing and updating? That's an open question for me; it's not the first time I've heard uF described as read only.
Considering the editing issue, what would you think about creating a more specific mime type for microformats? Maybe something like <atom:content type='xhtml+hcard'>. This would identify to the client that the content is an hcard encapsulated in xhtml. The client could then post/put any valid hcard regardless of the xhtml scaffolding, and the server could safely ignore the xhtml markup and only be concerned with whether the submitted content is valid hcard.
Another benefit of this would be for alternative serializations of the feed such as JSON. For instance abderra has a fairly gnarly but probably necessary way of representing foreign markup in its JSON serialization. For xhtml+hcard, abderra could use this as a clue to instead output hcard key-value pairs without the xhtml scaffolding, providing a much more concise and easy to manipulate json object without the risk of any data loss. Similarly a client could put/post a json hcard object without all the unnecessary xhtml filler.