Re: libvc 003 released with vCard 2.1 compatibility and question for the public

Thanks.

I will take a look at this.  The one thing important
to me in one project that I am working on is to
support Japanese vCard with the Furigana or Ruby. 
Next week, I will try to experiment and evaluate
Microsoft's format.

Also, do the vCards support Unicode.  MacOS X supports
UTF-16 Unicode cards.  I also experimented with
Apple's iPod, and they support various forms of
UNICODE for notes.  I imagine the same will work for
vCards in the iPod.

Eventually, I would like to have PIM software that can
support Palm, WinCE, iPod, iSync, and Outlook.  I
looked for available freeware/open-source
applications, and so far it looks like the Mozilla is
the best option for now.

  = Joaquin


--- Andrew Hsu <[email protected]> wrote:
> 
> Announcement:
> 
> Hello,
> 
> Libvc has just been released with the ability to
> parse vCard 2.1
> files.  The previous release had choked on vCard 2.1
> parameters.
> This new fix means that libvc can read in Microsoft
> vCard files.
> 
> The details about obtaining the new release can be
> found on the web
> site:
> 
> http://rolo.sf.net/
> 
>                              ~~~
> 
> Question for the public:
> 
> The problem that was preventing libvc from reading
> in vCard 2.1
> files before was the parameter parsing.
> 
>   TEL;PREF:+64-9-111-2222
> 
> would produce an error because libvc was expecting
> vCard 3.0 format:
> 
>   TEL;TYPE=PREF:+64-9-111-2222
> 
> in libvc 003, it will parse the vCard 2.1 format and
> turn it into
> the vCard 3.0 format on output.
> 
> This leads to the side-effect of parsing multiple
> vCard 2.1 parameters
> as separate name-value pairs.  For example, if libvc
> 003 comes
> across:
> 
>   TEL;PREF;HOME:+64-9-111-2222
> 
> It will turn it into:
> 
>   TEL;TYPE=PREF;TYPE=HOME:+64-9-111-2222
> 
> instead of smushing all the parameter values with
> the same parameter
> name like:
> 
>   TEL;TYPE=PREF,HOME:+64-9-111-2222
> 
> However, the next iteration of libvc can be made to
> smush parameters
> with the same name into one parameter name with a
> parameter list,
> but this would need some extra smarts coded into the
> library.
> 
> And this ultimately leads to my question for the
> public:  Is vCard
> intended to be "human friendly for reading and
> writing cards" or
> is it intended to be just "human readable".  For if
> it was intended
> to be "human readable", then the specification would
> benefit from
> the strict definition of how to list the parameter
> values of the
> same parameter name: either in list format or in
> separate name-value
> pairs (i.e. either like TYPE=PREF,HOME or like
> TYPE=PREF;TYPE=HOME).
> A strict definition would make writing a parser much
> easier.  However,
> if vCard was intended to be "human friendly for
> reading and writing",
> perhaps the flexibility allows a human to choose the
> format that
> is "easier to type" or "easier for the user to
> conceptualize".  What
> are people's thoughts on the matter?
> 
> Cheers,
> Andrew
> 
> -- 
>  .
>  .  Andrew Hsu
>  .  email: [email protected]
>  .  email: [email protected]
>  .


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com