[Cosmo-dev] VCard Parsing in Cosmo

[Vinubalaji Gopal]

On Wed, 2006-07-19 at 15:17 -0700, Brian Moseley wrote:

> good question. the draft seems to be silent on this, altho perhaps it
> assumes an understanding of the vcard rfc that neither you nor i have
> attained :)
> 

Actually the draft does answer the question, but it does not give an
example on how to use it. Yeh it does assume a fair understanding of the
vcard rfc.


>From the RFC 2426(VCard): 
   Address type information:

   Type special notes: The structured type value consists of a sequence
   of address components. The component values MUST be specified in
   their corresponding position. The structured type value corresponds,
   in sequence, to the post office box; the extended address; the street
   address; the locality (e.g., city); the region (e.g., state or
   province); the postal code; the country name. When a component value
   is missing, the associated component separator MUST still be
   specified.

There are more types like telephone types (work, home, etc), label types (home, intl, postal, etc), 
email types (internet, pref, etc). The TYPE is referred to as parameters in vcard context. Other parameters
include and is not limited to VALUE, ENCODING, LANGUAGE, x-name. 

Obviously the search in the case of address would be for a home address or work address.
For example I may be searching for my contacts working in San Francisco.


For a normal address query like:
<C:prop-filter name="ADR"> 
    <C:text-match match-type="equals">First street</C:text-match>
</C:prop-filter>

Instead if the client wants to search only the home address  of all 
her vcard resources, she should be doing something like this

<C:prop-filter name="ADR"> 
   <C:param-filter name="TYPE"> 
      <C:text-match match-type="equals">home</C:text-match>
    </C:param>
    <C:text-match match-type="equals">First street</C:text-match>
</C:prop-filter>
 
After reading through the CardDAV RFC I figured out that param-filter
lets you define a fine tuned search and I hope my interpretation of
<!ELEMENT prop-filter (is-defined | text-match)? param-filter*>
is correct. I interpreted it as a regular expression and I guess that is
how it works.


Similarly to search ADR with TYPE parameter set, the following request
can be used. (which is not a really useful query)

<C:prop-filter name="ADR"> 
   <C:param-filter name="TYPE"> 
      <C:is-defined />
    </C:param>
    <C:text-match match-type="equals">First street</C:text-match>
</C:prop-filter>


> vcard-adr:;;123 Main Street;Any Town;CA;91921-1234
> vcard-adr-type-dom=true
> vcard-adr-type-home=true
> vcard-adr-type-postal=true
> vcard-adr-type-parcel=true
I am worried that the mapping between the types and the corresponding address will be lost.

The ideal way will be to store something like:
vcard-adr-home:my home address
vcard-adr-work:my work address
.
.

Since it wont be generic for all the parameters, we can have something
like this:
vcard-adr:;;123 Main Street;Any Town;CA;91921-1234
vcard-adr-type: dom,home,postal,parcel


So for other parameters it will be vcard-photo-value or
vcard-photo-encoding. 

But I think we need to identify all the parameter, so we should have
something like (unless jackrabbit has some other means of indicating
that this property is a parameter)
vcard-adr-param-type:dom,home,postal,parcel
vcard-photo-param-encoding:B
vcard-photo-param-type:jpeg

Storing it this way I don't think its possible to do a fine tuned query.
For example doing a search for "Main" and parameter "parcel" will match
this:
vcard-adr:;;123 Main Street;Any Town;CA;91921-1234
Eventhough the parcel part of vcard-adr has no "Main" in it. 
If we want to do a more fine tuned query, we have to parse vcard-adr for
each report (adbk-query) and I am not sure if CardDAV addresses this
concern? 

Thoughts?