canmove, Confirmed users
2,887
edits
VCard4: Difference between revisions
Jump to navigation
Jump to search
reviewed thru section 6.2.8
(reviewed thru section 6.1.5) |
(reviewed thru section 6.2.8) |
||
| Line 217: | Line 217: | ||
Seriously? An XML property that represents all the rest of the data in the same vCard? Ugh. Which do you trust? The XML or the actual vCard properties? | Seriously? An XML property that represents all the rest of the data in the same vCard? Ugh. Which do you trust? The XML or the actual vCard properties? | ||
=== section 6.2. Identification Properties === | |||
6.2. Identification Properties | |||
no comment on intro. | |||
=== section 6.2.1. FN === | |||
6.2.1. FN | |||
The possibility of having multiple FNs is introduced, which seems both reasonable and useful in practice from personal experience with developing address book code. | |||
However, there is no advice/guidance given regarding how to treat multiple FNs and thus I fear this new capability may introduce some interoperability problems. | |||
I suggest some wording and examples clarifying what the purpose may be for multiple FNs, e.g. multiple ways of displaying a name (perhaps some with additional names, some without), or multiple ways (character sets? languages?) to write a name (e.g. a Japanese name may be written with Kanji or transliterated Hiragana). | |||
=== section 6.2.2. N === | |||
Not requiring an N is a big improvement. | |||
The new N structure is different enough from vCard3 to be problematic. | |||
Minor change: | |||
* Use "family name" as a primary (perhaps with "also known as surname") since vCard3 referred to "family name", and hCard adopted that wording in the subproperty "family-name". | |||
Major changes: | |||
* Consider allowing multiple family names. In my experience giving microformats workshops around the world, I have found that there are languages/cultures that actually use multiple family names in practice, e.g. in Spain. | |||
* Restore the "additional name" structural component that was in vCard3 for better schematic compatibility. | |||
* Am ok with multiple Given Names as that does reflect common practice. | |||
=== section 6.2.3. NICKNAME === | |||
6.2.3. NICKNAME | |||
"belonging to a person, place, or thing" - avoid such itemizations of what a vCard could represent as it will be (is) a maintenance nightmare. | |||
Use "belonging to the object the vCard represents" instead. | |||
=== section 6.2.4. PHOTO === | |||
6.2.4. PHOTO | |||
Seems about the same as vCard3. | |||
Provide a data: URI example as implementations do seem to support that, and note how the data URI may contain the content/MIME-type and thus that can be used instead of the FMTTYPE param. For reference: | |||
http://en.wikipedia.org/wiki/Data_URI_scheme | |||
<nowiki>data:[<MIME-type>][;charset=<encoding>][;base64],<data></nowiki> | |||
=== section 6.2.5. BDAY === | |||
6.2.5. BDAY | |||
The expansion of permitting month-day only or year only are both very good. Would also suggest permitting year-month as well, e.g. 1996-04 | |||
=== section 6.2.6. DDAY === | |||
6.2.6. DDAY | |||
No evidence of address books that support this property have been presented. | |||
This would make more sense as part of a "genealogy" extension to vCard4 rather than part of the core. | |||
That being said: | |||
I for one have personally found it there to be a user-interface challenge in managing the contact information in an address book of people that have passed away. | |||
While some may suggest simply deleting such entries, I don't think that reflects that necessary history/attachment/notes of common usage of such address book entries. | |||
However, given that address books are often used to "auto-fill/suggest" things like email program "To:" fields etc. (e.g. Mail.app on MacOSX with the Address Book app), it makes sense to provide some way to mark a contact as deceased so that they don't show up in auto-fill/suggest user interfaces. | |||
A DDAY property could serve as a proxy for such a "deceased" checkbox on an entry. | |||
It should explicitly allow the same data type as BDAY, and provide examples accordingly. | |||
Thus while there is no existing evidence of address books that provide this kind of user interface feature, I believe this may be an instance where it makes sense to add this field, given the *address book* use cases documented above. | |||
I would also be ok postponing this property to a "genealogy" extension. | |||
=== section 6.2.7. BIRTH === | |||
6.2.7. BIRTH | |||
No evidence of address books that support this property have been presented. | |||
This would make more sense as part of a "genealogy" extension to vCard4 rather than part of the core. | |||
And this is a horrible property name to boot for a "location". | |||
Recommendation: drop from vCard4. | |||
=== section 6.2.8. DEATH === | |||
6.2.8. DEATH | |||
No evidence of address books that support this property have been presented. | |||
This would make more sense as part of a "genealogy" extension to vCard4 rather than part of the core. | |||
And this is a horrible property name to boot for a "location". | |||
Recommendation: drop from vCard4. | |||
=== in progress review continues here ... === | |||
== related == | == related == | ||
* [[Standards]] | * [[Standards]] | ||