Subject: [Jcardcal] jCard implementation

From: Michael Angstadt <[email-masked]>
Date: Thu, 18 Apr 2013 14:27:47 -0400

I've just released a new version of my Java vCard library, ez-vcard.
This new version includes support for jCard.

Implementing the specification was pretty straight-forward.  One thing
that I have found troublesome is the fact that vCard uses the "basic"
format for dates (e.g. "20130418T104800Z"), while jCard uses the
"extended" format (e.g. "2013-04-18T10:48:00Z").  For date/time
values, this is fine.  But for reduced accuracy dates, this causes
problems, at least with my library.  This is because my library
represents a reduced accuracy date as a String, so converting between
basic and extended formats is more difficult.

I plan on keeping my implementation updated as the jCard and jCal
drafts progress.

http://code.google.com/p/ez-vcard

Thanks,
Mike

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Apr 2013 13:07:28 -0600

> This new version includes support for jCard.
Thanks for the report!

I'd encourage the jcard/jcal authors to add an Implementation Status
section to their documents, as described more fully here:

https://datatracker.ietf.org/doc/draft-sheffer-running-code/

Peter, as co-chair

---

From: Philipp Kewisch <[email-masked]>
Date: Thu, 18 Apr 2013 21:35:29 +0200

I've already added this for jCal, will do the same for jCard.

Philipp

On 4/18/13 9:07 PM, Peter Saint-Andre wrote:
> _______________________________________________
> jcardcal mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jcardcal

---

From: Simon Perreault <[email-masked]>
Date: Fri, 19 Apr 2013 09:36:21 +0200

> basic and extended formats is more difficult.

Does the difficulty arise when converting between jCard and {v,x}Card, 
or does standalone jCard possess this inherent problem?

The first I think we can deal with, the second is more problematic.

Simon

---

From: Michael Angstadt <[email-masked]>
Date: Fri, 19 Apr 2013 16:27:46 -0400

On Fri, Apr 19, 2013 at 3:36 AM, Simon Perreault
<[email-masked]> wrote:
> Does the difficulty arise when converting between jCard and {v,x}Card, or
> does standalone jCard possess this inherent problem?

It arises when converting between jCard and {v,x}Card.  Converting a
"basic" reduced accuracy date to its "extended" version (and vice
versa) seems to be non-trivial, for two reasons.

(1) Hyphen characters are not just cosmetic--they can also have
special meaning.  For example, in the dates below, the two dashes at
the start of this date signify that it lacks a "year" component.
These dashes are part of the syntax and are required in both "basic"
and "extended" versions.  The "extended" format of this date inserts a
cosmetic hyphen to separate the month and the date.  So, in
"extended", hyphens are both cosmetic and meaningful.

Basic: --0412
Extended: --04-12

(2) Since there are so many variations of a reduced accuracy
date/time, it is difficult (but not impossible, I would think) to tell
where the hyphens/colons should be inserted when converting from
"basic" to "extended".

Also:

I just noticed a typo in the jCard specs.  At the top of page 12, one
of the examples of a reduced accuracy date uses the basic format,
instead of the extended format:

["bday", {}, "date", "--0412"],

should be

["bday", {}, "date", "--04-12"],

I don't know why they had to invent two separate formats.  It just
causes headaches... :(

Thanks,
Mike

---

From: Simon Perreault <[email-masked]>
Date: Mon, 22 Apr 2013 09:56:29 +0200

> where the hyphens/colons should be inserted when converting from

I see. Thanks for the feedback.

> ["bday", {}, "date", "--04-12"],

This is great. It shows it's really easy to mix up the two formats.

Are we setting up the perfect interoperability trap?

> I don't know why they had to invent two separate formats.  It just

I would tend to agree.

Simon