Jump to: navigation, search

hCard design methodology


This page is an informative explanatory section of the hCard specification.

This page captures some of the design methodology that went into the hCard microformat.

Most of the details of hCard were very deliberately designed based on principles. By capturing some of those principles and methodological techniques, hopefully future microformats can benefit by reusing some of this methodology.

Tantek Çelik

Semantic XHTML Design Principles

The semantic-xhtml-design-principles were largely created and captured as a result of explicit design decisions for how to best re-use vCard RFC2426 terminology in the context of semantic XHTML.

In particular:

For hCard, the pre-existing, established, well-supported standard re-used was/is vCard.

vCard uses case-insensitive identifiers, but by convention most vCards have, and vCard implementations produce, all UPPERCASE identifiers, e.g. VCARD, N, FN etc. Since the HTML4 'class' attribute is case-sensitive, for microformats I had to pick a specific case to use for property names. I decided to explicitly follow the precedent and example set by XHTML from HTML4 of using the lowercase version of element names from HTML4 which itself similar to vCard had case-insensitive element names (due to its use of SGML) and by convention used all UPPERCASE element names in documentation.

Thus where HTML4 to XHTML looked like this:

vCard to hCard looked like this:

In the vCard specification, properties are referred to has "types", and thus the above principle invokes that same language to refer to such "types", specifically those that have some structure to them, with a set of values that relate specific semantics.

The primary example of this in hCard are the "n" and "adr" properties, each of which have sub-properties (e.g. "given-name", "family-name", etc. for "n", "street-address", "locality", etc. for "adr").

There are several properties in vCard that are either plural (e.g. CATEGORIES) or are simply defined to take multiple values (e.g. NICKNAME), or are sub-properties that are plural (e.g. additional names). As one of few exceptions to the "reuse names exactly" aka "don't change the names" design principle, plural names of properties or sub-properties are explicitly changed to their singular equivalents, e.g.:

And in all cases of such plural or multi-valued properties, the hCard specification permits multiple instances of the singular form which are then combined as appropriate to the equivalent property when transforming to vCard.

Motivated originally by the development of hCalendar which itself is based on iCalendar RFC2445, which needed a way to capture and represent datetimes, this technique is similarly used in several instances in hCard, e.g.

see also

hcard-design-methodology was last modified: Saturday, March 30th, 2013