Re: revised DTD

[Martin Lee <martin@xxxxxxxxxxxx>]

The handling of composite names I believe is a weakness in the
specification.

The current specification allows multiple birthdays, which must be
incorrect (reigning monarchs are the only exception to
this, but date of coronation should probably be specified by a user
defined tag).

The question boils down to is a composite name a single name composed of
two words that may be names by themselves ?
or is it two separate names that are always used in conjunction with
each other ?

For forenames, I believe the criteria depends on how the individual is
addressed. An individual Jean Marie, may always be
addressed as Jean Marie, never Jean or Marie, therefore their first name
should be <given>Jean Marie</given>, to use
<given>Jean</given><given>Marie</given> is confusing. Is there a choice
in which first name to use ? Which given name
has precedence over the other ? Is
<given>Marie</given><given>Jean</given> equivalent ?
If they are addressed as Jean, and not Jean Marie, then the precedence
of Jean over Marie should be indicated by marking
up Marie as <given>Jean</given><other>Marie</other>.


Composite surnames are more complicated. Yes, many cultures do use
surnames which are a composite of Father's surname
and Mother's surname, yet there is still a notion of precedence to
prevent grandchildren inheriting four surnames, and so on
concatenating surnames throughout generations.
i.e. Father : forename A-B
Mother: forename C-D
Child: A-C
Grandchild: A-E

not Child: A-B C-D
Grandchild: A-B C-D E etc.

With the use of two family tags it may be possible to include in an
implementation that is required to address the problems of
inheritance of multiple surnames an attribute to indicate which surname,
if not both, is inherited by children.
As far as I know, in all modern cultures, surnames are limited to a
maximum of two. There is no way to express this limitation
in XML unless we specify that individuals can only have one single
surname that may be composite, the example I gave in an
earlier post being <family>Palmer Tompkinson</family> not
<family>Palmer</family><family>Tomkinson</family>. This
restriction being to identify rogue data, an individual who is described
by vCard-XML data as possessing 100 surnames is likely
to be an erroneous anomaly and not a valid customer.
I can think of one exception to this rule, the biblical notation of
describing individuals as son of X, son of Y, son of Z etc. where
each 'son of ...' may be considered to be a separate family name, or
possibly the whole string as a single family name.

I'd strongly argue that the number of forenames needs to be limited to a
maximum fixed number. If this limitation is going to
exist in an implementation, it would be useful to agree on the
limitation before hand and have it fixed in the specification initially.



Martin




Frank_Dawson@xxxxxxxxx wrote:

>
> Martin:
>
> A separate response about the proposed changes to the "N" property is
> required.
>
> >The number of elements and entities that can occur many times has
> >been reduced. Although this does not form a truly identical XML
> >representation for vCard as specified in RFC 2426, it does form a
> more
> >meaningful representation of the data. e.g. you can only have one
> >first name, one family name, and one birthday.
>
> There is a real world requirement for supporting multiple family
> names. For example, in Hispanic cultures, the family name is
> multi-part where the first is typically the father's family name and
> the second is the mother's family name. In addition, there are many
> cultures where multiple first names are specified. These are not
> other, middle names.
>
> We should not change the content model for this property. It would
> definitely restrict the Internationalization of vCard.
>
> In the revised vCard XML DTD, I will leave the content model as it
> was.
>
> -- Frank
>
>

begin:vcard 
n:Lee;Martin
tel;fax:+44 (207) 757 2699
tel;work:+44 (207) 757 2659
x-mozilla-html:FALSE
url:http://www.ebookers.com
org:Ebookers.com
adr:;;34-42 Woburn Place;London;;WC1H 0TA;England
version:2.1
email;internet:martin@xxxxxxxxxxxx
title:Ecommerce Programmer
x-mozilla-cpt:;25760
fn:Martin Lee
end:vcard