Difference between revisions of "hcard-singular-properties"
(Corrected Author URLs)
(→n: No legal precedent for single-name-only in UK, for example)
|Line 13:||Line 13:|
=== n ===
=== n ===
The vCard represents a single directory object.
The vCard represents a single directory object. Legal precedents afford a person a single given-name and family-name, thus only a single "n" property is permitted.
=== fn ===
=== fn ===
Revision as of 19:17, 26 January 2007
hCard singular properties
This is an explanation of the list of singular properties in hCard.
The analysis here is derived from a thorough reading and analysis of the specific property definitions in the vCard RFC 2426 spec, along with reasoning using physics, and legal name precedents.
This summary is provided because that thorough reading and analysis takes a long time, and while repeatable, is not something that is worth encumbering other developers with.
The vCard represents a single directory object. Legal precedents in some jurisdictions afford a person a single given-name and family-name, thus only a single "n" property is permitted.
A person has only one "best" / most preferred way of formatting their name, and legally organizations have only a single name, thus "fn" is singular.
When sorting a name, it doesn't make sense for it to have more than way of sorting it, thus "sort-string" must be singular.
A person only has a single physical birthday (reincarnation cannot be scientifically substantiated and thus constitues the creation of a new directory object rather than the re-birth of an existing object, and being "born again" is not the physical event that "bday" represents). Thus "bday" is singular.
The "geo" property represents the person's actual location, not a coordinate approximation of an "adr". A person cannot be in more than one location at a time. Thus a person can only have a single "geo" property.
The "tz" property is the same. A person can only be in a single time zone at a time.
Entire vCard Properties
The "class" property indicates the confidentiality/access classification of the hCard as a whole, and thus it only makes sense for there to be one (or rather, makes no sense for there to be more than one).
The "rev" property represents the datetime of the revision of the hCard as a whole, thus it doesn't make sense for there to be more than one.
The "uid" property applies to the hCard as a whole. It doesn't make sense for an hCard to have more than one "uid".