vCard XML DTD comments 02

This is a multi-part message in MIME format.
--------------DD7C5B70B50BEF9DE833260E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Comments about:   The vCard v3.0 XML DTD

Commentor:   Randal Leavitt,   email: [email protected]

1.   I am interested in creating French and English vCards.  The DTD
seems to allow this by specifying the 'encoding' attribute with a value
of "UTF-8" for the DTD.  However, if we want to have a vCard in Chinese
what do we do?  Tokens such as "VOICE" and "MSG" will not be vary
understandable in China.  I think we need a separate DTD for each
language.

2.  In Section 2 the attribute "lang" is defined.  I think it would be
better to declare this attribute as "xml:lang" to more closely follow
the XML standard.

3.  Several attributes, (e.g. del.type, tel.type, email.type), are
specified as "NMTOKENS".  This makes it more difficult to automate
checking for correctness.  Many people will use incorrect values for
these attributes, and processors will not be able to detect this.  Also,
the NMTOKENS approach will make it more difficult to search for useful
information such as the home telephone number of a person in a list.
These attributes should be specified as enumerated lists instead, with
values expressed in lower case.  This may necessitate more attributes to
allow for all the combinations needed.

4. The "lang" attribute is specified for many of the vCard elements.
This is not pragmatic.  It should only be an attribute of the vCard
element itself, and should apply to the whole card.  I do not want cards
that are half French and half English.  I want a French business card
and an English business card, and I will give the appropriate one out
depending on the context.

5.  In the entity "prop.tel" I would include another child element
called "web" or "net" and remove the "url" element in "prop.exp".  My
email and web addresses are the most important.  One might even consider
an "ftp" element here as well.

6.  The attribute "value" is defined in two places (for fn and n), but
does not seem to have any use.  I think it can be deleted.  At the very
least it should be defined in one place as an entity and referenced for
these elements.

7.  The element "n" forces me to give my family name first.  I just hate
that.  Non-computer people think this convention is insane.  The
specification should allow me to specifiy these in any order.

8.  The element "n" will be valid if both the family name and given name
are omitted.  I think we should insist on at least one of these always
being present.

9.  The element "sort-string" is not needed.  It should be deleted.

10.  In the simple vCard example in Section 4.1, the DOCTYPE element
also requires a system literal to specify where the DTD can be found.
This comment applies to every example.

11.  In the simple vCard example in Section 4.1, the vCard element
declares a "VERSION" attribute, while the DTD defines this attribute as
"version"


--------------DD7C5B70B50BEF9DE833260E
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Randal Leavitt
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Randal Leavitt
n:              Leavitt;Randal
email;internet: [email protected]
note:           Ottawa, Ontario, Canada
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------DD7C5B70B50BEF9DE833260E--