[Cosmo-dev] VCard Parsing in Cosmo

[Brian Moseley]

On 7/20/06, Vinubalaji Gopal <vinu at osafoundation.org> wrote:

> >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.

note that the excerpt from the rfc and the subsquent paragraph of your
message are talking about two different topics. there is no
relationship between the value of the ADR property and the value of
the TYPE parameter. specifically, there is no correspondence between
the individual elements of the TYPE value and the individual elements
of the ADR value.

> 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>

those both look right.

> 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.

you interpreted what as a regular expression? if you look at the
definition of the carddav text-match element, you'll see that there
are several "match types".

> > 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.

what mapping? the vcard property says that 123 main street, any town
ca, 91921-1234 is a domicile address, a home address, a postal
address, and a parcel address. the individual address types are not
related to individual segments of the property value.

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

there would presumably be two separate ADR properties for home address
and 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

we could, but i think it will be harder to construct jcr xpath queries
to match this schema.

> 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

the hierarchical structure of the jcr property name indicates whether
it represents a vcard property or vcard parameter.

vcard-adr:         <- property (2 name segments)
vcard-adr-type   <- parameter (3 name segments)

> 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.

as i've alluded to a couple times above, i think you're
misintrerpreting how the ADR value and the TYPE value are related
(they're not).

> 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?
>
>
>
>