validating microformats (was Re: [uf-discuss] Google Gdata new syndication protocol!)

Mark Pilgrim pilgrim at
Fri Apr 21 12:29:24 PDT 2006

On 4/21/06, Mark Pilgrim <pilgrim at> wrote:
> Perhaps the only way to convince you that a microformats validator would
> be useful is to build the validator I'm imagining and show you.

On the road to working code, here are some notes I threw together on
the sorts of things I would expect a microformats validator to catch. 
I concentrated on hCard since it's complex and I'm familiar with it,
but many of the rules would apply to any microformat.

Errors (the W3C's XHTML validator won't catch any of these):

- Properties that are supposed to have a URI value but do not conform
to RFC 3986

<address class="vcard"><span class="photo">This is a photo if my

- URI property with data: URI value that does not conform to RFC 2397

- email property value with a mailto: URI that does not conform to RFC 2368

- date property with non-date value (or illegal date, or date in wrong format)

<address class="vcard"><span class="bday">April 21th, 2006</abbr></address>
<address class="vcard"><span class="bday">1993-06-31</span></address>
<address class="vcard"><span class="rev">1993-10-15T25:01:00Z</span></address>
<address class="vcard"><abbr class="rev" title="Fri, 21 Apr 2006
04:39:10 +0000">April 21th, 2006</abbr></address>

- geo/latitude and geo/longitude properties with improper values

<address class="vcard"><span class="geo"><span class="latitude">North
<address class="vcard"><span class="geo"><span

- Section 2.4.3 of RFC 2426 says phone numbers are supposed to conform
to [CCITT E.163] and [CCITT X.121] (haven't looked into those yet)

- tz property value that does not conform to section 2.4.4 of RFC 2426

- agent property value that is not an hCard

- required FN property missing (see section 1 of RFC 2426)

- <abbr> without title attribute (see )

- <img> without an alt attribute (only an error if it has an hCard
class that is not a URI property, see )

- illegal property present (NAME, PROFILE, SOURCE, PRODID, VERSION,
see )

<address class="vcard"><span class="prodid">-//ONLINE
DIRECTORY//NONSGML Version 1//EN</span></address>

- more than one sort-string property present

<address class="vcard">
<span class="fn n">
 <span class="additional-names">Robert</span>
 <span class="family-name sort-string">Pau</span>
 <span class="given-name sort-string">Shou Chang</span>

- N property present and non-empty when FN and ORG properties are also
present and have the same value as each other (see )

- N property missing and FN property is not exactly two words
separated by whitespace (see )

Warnings (may indicate publishing errors and/or cause interoperability
problems for consumers):

- no profile URI present (can only be a warning once we, you know,
define a profile URI)

- property with empty value (that does not match one of the
error-producing rules above)

<address class="vcard"><span class="honorific-suffix"></span></address>

- subproperty out of its proper container

<address class="vcard"><span class="given-name">Mark</span></address>

- type with no value (this may be an error, I can't tell)

<address class="vcard"><span class="tel"><span
class="type">home</span>: +1.415.555.1212</span></address>

- type with a value not defined in RFC 2426 (it is not clear from
section 3.2.1 whether this is an error)

<address class="vcard"><div class="label"><abbr class="type"
title="foo">my new adr type</abbr></div></address>

- geo information with latitude but not longitude (or vice-versa)

<address class="vcard"><span class="geo"><span


More information about the microformats-discuss mailing list