Ok the order that names are displayed is really down to the application
displaying it ..
vcard defines five specific elements for names given family other title
sufix
It also has the FN formated name field
using this schema we should be able to repersent most names .. For those
contacts that use there family name first you enter it into given name
field .. unless this is more common to you then the other in that case
you set up the format to display family name first and reverse the names
of western contacts ..
Any simple naming system will allow us to handle this ,, for serching
etc.
Also when an application serches the name fields if we usre the stanard
vCard format then its a mater of a simple pattern match
select person_id from gpe_contacts where name is like "N*:*alan*"
This pattern will ignore any non name field (not nessesery if we store
names in a smaller table but pull up any one with the name alan in there
Family Given or middle name if you want to be a bit more selective IE
only family names Hall then this
select person_id from gpe_contacts where name is like "N*:Hall;*"
just first names
select person_id from gpe_contacts where name is like "N*:*;Dave;*"
the flexability if fairly effective .. and the use of simple macros
allows easy specification of serches so the UI would only see a list of
fields to search.
I personally feel that the N and FN fields of the vCard should be in a
seperate table.
IE
#The following fields define the N and FN options within vCard
#version 2.1
create table gpe_contact_name(
URN int NOT NULL,
person_id int NOT NULL,
name text NOT NULL,
formatted_name text,
PRIMARY_KEY(URN, person_id, name)
)
and all other information should be stored within the same table as
multiple rows for each contact ID
create table gpe_contact_names(
person_id int NOT NULL,
element name text NOT NULL,
element_value text
)
The URN within gpe_contact_name is a Unique Resource Number as defined
within the schema currently on the gpe.handhelds.org page
Im of the opinion that we probably do not need a person_id and a URN but
could just use URN.
This would allow us to have the table
create table gpe_links(
idint NOT NULL,
descriptiontext,
sourceURNtext NOT NULL,
destURNtext NOT NULL
)
as difined within the above mentioned schema linking event to contacts
etc etc
doing this requires that the standard is very strict about checking for
a URN within source or dest when deleteing it from the database ..
Pity SQLite dose not have triggers.
Im also curiose about how we handle the creation of Unique URNs or for
that matter any of the ids used within the database.
it would be nice to create a very simple script that allows a program to
check for the next available URN
On Thu, 2002-06-06 at 15:36, Damien Tanner wrote:
> In my usefull opinion, just about everyone I know I call by their first
> name, so defently a ability to configure the display of names whould be
> very usefull, I hate it how other mail/contacts apps put the last name
> first etc...
>
> dctanner.
>
> On Thu, 2002-06-06 at 19:19, Noel J. Bergman wrote:
> > > It's pretty culturally specific to expect the [Mr] John R Smith [III]
> >
> > Exactly! :-)
> >
> > > it gets unclear what you should do e.g. about entering
> > > someone whose family name comes first in their name.
> >
> > Uh ... provide an option that says how to render each name?
> >
> > > my father, for example, is 'Iain Allan' but 'J.N. Allan',
> >
> > Is Iain a nickname? Another valid field.
> >
> > First: J
> > Middle: N
> > Last: Allan
> > Nick: Iain
> > DisplayAs: nickname + ' ' + last
> >
> > > while lots of people have more than three names
> >
> > Lump them into the middle name (Mary, Katherine Elizabeth Reingold, Smith),
> > unless they are used as part of the surname (Aranxta, ?, Sanchez-Viccario).
> >
> > The DisplayAs approach also allows things like (first + '"' + nick + '"' +
> > last), (last + ", " + first + middle); or other format. The resulting
> > string is a value like any other, which we can use to sort, search, group,
> > etc.
> >
> > --- Noel
> >
> > _______________________________________________
> > GPE mailing list
> > GPE@handhelds.org
> > http://handhelds.org/mailman/listinfo/gpe
>
> _______________________________________________
> GPE mailing list
> GPE@handhelds.org
> http://handhelds.org/mailman/listinfo/gpe
>
Received on Thu Jun 06 20:27:33 2002
This archive was generated by hypermail 2.1.8 : Tue May 04 2004 - 09:41:28 EDT