vCard v3.0 XML DTD (v01)

[Anders Kristensen <ak@xxxxxxxxxxxxxxx>]

Hello everybody,

I read the I-D giving an XML DTD for vCard and have a couple of
comments. My apologies for rambling along - I got a bit carried away ;-)

Here goes.

I think it would be a good idea to give a URL which can act as the XML
namespace identifier for XML encoded vCards.

Would it be possible to restrict dates (the bday element/attribute) to
be the W3C recommended subset of ISO 8601
(http://www.w3.org/TR/NOTE-datetime-970915.html)? Probably not if vCard
allows the full complexity of ISO 8601. Would be desirable, though. When
will people learn that options are not always good?

Page 2:
   The [VCARD] specification defines a strongly typed object format.
   This level of data typing is difficult to express in the XML content
   model since it only supports the parsable character data (i.e.,
   PCDATA") content information. The DTD attempts to convey the vCard's
   strong data typing with a "value" attribute on each property element.

Presumably you mean "type" attribute?

And while we're at the nits: you get the vCard version attribute wrong
in all examples - "1.0" rather than "3.0". You're also not consistent
with the case of attributes - XML settled on case-sensistive element and
attribute names, right?

Why not define the url element to be a 'simple' XLink, e.g.

<!ELEMENT url EMPTY>
<!ATTLIST url
    xml:link    CDATA   #FIXED "simple"
    href        CDATA   #REQUIRED>

or something like that (see a element below)? This allows XLink aware,
vCard *unaware* apps to treat the url as a hyperlink.

On embedding base64 encoded binary data in XML documents: I generally
prefer an alternative approach, namely to use references and MHTML and
the cid URL type. UAs may find this harder to handle, I don't know, but
it seems like the cleaner approach of the two.

I would make the same comment about the handling of *embedded* vCards.
In this case I think it's much better to refer to a remote vCard, say,
using an http URL, or to a local one transmitted or encoded using MHTML.
By not embedding the vCard directly you get a more uniform handling as
it will just be a URI regardless of whether the subordinate vCard is
local or remote. [BTW <draft-masinter-url-data-01.txt> described how to
include literal base64 encoded data into a 'data' URL.]

You use XML entities as the mechanism for refering to remote vCards. I
would much prefer just using URLs the way they're used in HTML (like
'simple' links in XLink - with a content-role attribute value of
'agent', say). IMHO it's kind of unfortunate that XML even provides two
mechanisms that can be used for such things. Using XML entities for
references to remote vCards means applications will have to parse at
least part of the DTD and authors and tools have to generate it. Using
HTML-ish URLs avoids this.

So my vCard could be (with a namespace):

<vc:vCard
   version="3.0"
   xmlsn:vc="http://www.ietf.org/RFC/vCard/xml";>
<fn>Anders Kristensen</fn>
<n><family>Kristensen</family><given>Anders</given></n>
<a role="url"
   href="http://www-uk.hpl.hp.com/people/ak/"; />
<a role="agent"
   href="cid:june.vcf"; />
<a role="brother"
   title="My brother Nicolai"
   href="http://foo.com/~nicolai/nk.vcf"; />
<a role="photo"
   show="embed"
   href="http://www-uk.hpl.hp.com/people/ak/ak.jpg"/>
<a href="mailto:ak@xxxxxxxxxxxxxxx"/>
<a tel.type="PREF WORK MSG"
   href="phone:+44-117-922-8164"/>
<a tel.pref="WORK FAX"
   href="phone:+44-117-922-8003"/>
</vc:vCard>

so the same "a" link element is used to reference different "objects"
(my URL, photo, email address, telephone, digital signature, related
vCards) all of which can either be remote or included in a related MIME
body part (in this case my agents vCard).

Note that all the attributes of the link element shown here are defined
by XLink and have defined semantics. The "role" attribute is the XLink
"content-role" which I've shorted to "role" using the attribute mapping
facility of XLink (to save typing and bandwidth). A standard set of
roles would be taken from the vCard spec but people can use their own
ones (maybe with an "x-" prefix). 

In the cases where the href URI *is* the content it might be desirable
to use a separate element. This is the case for the email address and
URL. If the generic a element is used it is implicit that the email
address given is mine, but then that's fine, right?

One might also want a separate element for the photo, although I don't
see the need for that. HTML does this. The HTML img tag signals that the
resource is an image and that it should be inlined. With XLink the
'show' attribute is used for signalling whether to inline the resource
or not.

I don't see the point of giving the content type in the link itself. If
the image/sound is remote, the content-type will typically be provided
by the transport, eg HTTP, and if it's given in an MHTML body part it
will be provided in the Content-Type header for that body part. It was
needed for base64 encoded, inline binary content but not if MHTML is
used. At least make it optional. I don't think that just because it's
given explicitly in the vCard notation the XML encoding also has to. 
Feel free to disagree violently.

The question of whether to use XML entities or URIs has an analogue in
formal public identifiers (FPIs). On the Web URIs are used as global
identifiers - as in XML namespaces. Again we have an SGML mechanism and
a "native Web" mechanism. For both entities vs URLs and FPIs vs URLs I
think it's true that the Web mechanism assumes the least about
cooperating UAs - in terms of capablities and shared knowledge.

Non-standard extensions: don't introduce your own "x-" namespace
mechanism. XML already has a perfectly fine one.

On a more speculative note, and not related to the XML encoding...

Would it be a good idea to define an element whose purpose it would be
to uniquely identify people? As vCards stand, if I want to find out
whether the person identified by two vCards are the same, I can only
compare values and it can't be done reliably (as people move about
etc).  In some countries, e.g. Denmark where I come from, everyone gets
a personal number at birth - it would be natural to *allow* the
recording of this information in vCards (for security reasons you'd want
to be careful who you give it to). Again this field could be a URI, e.g.
of the form pid:dk:010269-7777. Countries without a personal ID could
use social security number or whatever.

Also would it be an idea for the vCard spec to define lists of people,
e.g. for exchange mailing lists or address books?

Regards,
Anders

-- 
Anders Kristensen <ak@xxxxxxxxxxxxxxx>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK