Even though I don't have any *major* objections I still wanted to raise some
concerns about the consequences of such highly specialized formats, all
similar but nevertheless not truly interoperable/compatible. As a developer
you basically have to write specific code for each of those formats.

I was wondering if it was ever considered to use, e.g., something like
JSON-LD [1] as the base for formats like these and limit the standardization
to a shared vocabulary (i.e., URLs for the required properties) and a set of
constraints and conventions captured in a profile (see [2] for details).

The advantage would be that much more code could be reused and
data-integration would become much simpler. It might look complicated at
first sight, but in reality most of what's needed is already there. For
example, the work to define URLs for the various properties for both
iCalendar [3] and vCard [4] has already been done at W3C (not as a REC
though).

So, a simple vCard represented in JSON-LD would look as follows:

{
  "@context": {
    "@vocab": "http://www.w3.org/2001/vcard-rdf/3.0#"
  },
  "FN": "John Doe",
  "ROLE": "Mr. Anonymous"
}

You would have to define a number of constraints in the form of a profile if
you also want clients that process this as JSON instead of JSON-LD to be
able to interpret the data. The reason is that in JSON-LD you can serialize
the exactly the same data in a number of different ways (e.g., you could use
different field names that still expand to the same URLs; the context
defines those mappings). JSON-only clients are less flexible and thus need
to know the exact structure and field names.

The question I thus would like to ask is: Is there a compelling reason why
this can't be based on a format as JSON-LD? Taking out the potential
complexity by requiring a profile defining a number of constraints on how
the data is serialized, I only see advantages of doing so.


Cheers,
Markus


Disclaimer: I'm one of the authors of JSON-LD.


[1] http://json-ld.org/spec/latest/json-ld-syntax/ (JSON-LD will become a
W3C REC soon; it will enter last call by the end of the month)
[2] http://tools.ietf.org/html/draft-wilde-profile-link
[3] http://www.w3.org/TR/rdfcal/
[4] http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/



--
Markus Lanthaler
@markuslanthaler



> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of Barry Leiba
> Sent: Wednesday, February 13, 2013 1:03 AM
> To: Cyrus Daboo
> Cc: CardDAV; calsify@ietf.org; IETF Apps Discuss
> Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft
> charter
> 
> This is going to be Pete's working group, but let me add one thing to
> what Cyrus said about the aggressive schedule and the "fast track":
> 
> A while ago, we chartered the imapmove working group on a very fast
> chartering schedule, and we're looking to do even more here.  The idea
> that "it takes too long to create a working group" is something we
> need to dispel.  In this case, we have an opportunity, with two
> back-to-back IESG telechats a week apart, so we are looking for *this
> Friday* (15 Feb) to put this on the telechat agenda for next week (21
> Feb), and to have it get final approval on the 28th.  That's three
> weeks from charter proposal to approval.
> 
> That means that we need to hear any *major* objections to this now --
> please have a look at this quickly and call out anything we've really
> goofed on before Friday.  We then have until next Thursday (21st) to
> get the details of the charter in shape for broad review.
> 
> Barry, Applications AD
> 
> On Tue, Feb 12, 2013 at 5:11 PM, Cyrus Daboo <cyrus@daboo.name> wrote:
> > Hi folks,
> > At the prompting of the Weirds WG there is a need to move more
> quickly on
> > developing specifications for JSON-based data formats for iCalendar
> and
> > vCard data, without necessarily waiting on other (proposed) JSON
> working
> > group work to proceed.
> >
> > A proposed charter for a "fast-track" Working Group is posted at
> > <http://trac.tools.ietf.org/wg/appsawg/trac/wiki/jcardcal> for
> feedback. The
> > charter defines aggressive milestones and attempts to limit the
> objectives
> > such that those are achievable. Please review and post comments back
> to the
> > apps-discuss list.
> >
> > Whilst initial focus will be on the draft charter, some drafts have
> already
> > been published describing possible (different) approaches. One for
> > iCalendar:
> > <https://datatracker.ietf.org/doc/draft-kewisch-et-al-icalendar-in-
> json/>,
> > and one for vCard:
> > <http://tools.ietf.org/id/draft-bhat-vcarddav-json-00.txt>. We also
> hope to
> > have an alternative jCard draft published in the next day or two that
> uses
> > the same approach as draft-kewisch-et-al-icalendar-in-json. These
> should
> > provide a good basis for initial input into the working group.
> >
> > --
> > Cyrus Daboo
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss