RE: Name relationships in vCard 3.0

[krauss@xxxxxxxxxxxxx]

Hey, you are very busy today!
;-)

Only a comment: here, in Brasil
 (we speek portuguese pt-BR), we use more FN than N
 because we not ordenate names by family name in general,
 in lists of names, and databases have
 only de "monolitical form", permited in FN,
 not de "splited form" used in N.


   Peter P. Krauss


PS: some systems use "automatic splitter" here, but they
  do errors because is very commom composed first name,
  like the son of our ex-president,

  FN: Fernando Henrique Cardoso Filho
  N: Cardoso; Fernando Henrique;;; Filho
  (where filho = son ~ Junior, Fernando Henrique=composed first name)


Citando "Roland H. Alden" <ralden@xxxxxxxxxx>:
>
>
> > 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".
>
>




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.