[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Name relationships in vCard 3.0
> If FN can not be derived from N, then there are a host of
> issues that need to be addressed, and as far as I can tell,
> have not been addressed in the RFC.
Perhaps. But if FN could be derived from N then there would be no need
for FN :)
I don't think there would be any particular problem if an application
ignored FN and just used, from N, pieces of "name" stuff that it felt
best able to process.
> For example, how do I
> display and sort by name in such a way that users won't be
> totally confused? For example, if FN:Dubya and N:Bush;George,
> I either need to display "George Bush" and sort by "George"
> and/or "Bush", or display (and sort by) "Dubya", but it makes
> no sense to display "Dubya" and sort based on "Bush;George".
In your example it might "make no sense" but there might be other
examples, from Japan perhaps, where what is sorted on and what is
displayed are quite unrelated.
> The first two cases make the secondary type (i.e. N or FN)
> irrelevant,
Yes indeed. They are "redundant" in that they encode the "same
information" in two different ways for which there is no well-defined
"mapping".