[uf-dev] What would a microformats validator look like?

[Mark Pilgrim]

On 4/20/06, Brian Suda <brian.suda at gmail.com> wrote:
> I wrote (and needs updating) a sort of hCard pre-flight check-list. It
> simply made sure there was an FN and N property.
>
> Other microformats such as XFN only have one property rel="{enumerated
> list}", but if you find a rel with a value that is NOT in that list,
> that doesn't mean the page doesn't validate!
>
> So what do we (or people want) when they say the word "validator"?

As the original author of the Feed Validator, I can say that there are
lots of opportunities to screw up microformats.  Many of them are
machine-detectable.

- Data formats of specific properties.  Dates are a huge problem in
RSS and Atom.  Microformats have dates.  I see to reason to think that
people will be any better specifying them in microformats.  Other
properties are defined as URIs, which also have a specific
validateable syntax.  Ditto geo properties.  Some properties in hCard
are enumerated types.  Etc.

- Cardinality.  Some things are allowed 0 or 1 times -- if they're
present twice, that's an error.  Other things are required exactly
once, so 0 or 2 times is an error.  Sometimes things aren't allowed in
combination.  Etc.

- Metadata.  Like missing profile URIs (once we, you know, define some
profile URIs and make them required).

- Warnings for probably mistakes.  An <abbr> in an hCard, with an
hCard class but no title attribute.  Or imagine something that looks
like an hCard, but is enclosed in an id="vcard" instead of
class="vcard".  Things like that could at least get a warning.  Feed
Validator issues warnings on a wide range of topics.

- Character encoding.  Many people get it wrong and/or rely on browser
auto-detection to correct it.  Many mismatches are machine-detectable.
 Feed Validator does this; the same detections would apply just as
well to microformats within XHTML.

--
Cheers,
-Mark