This is the UK Web Focus blog, written by Brian Kelly, UKOLN. UKOLN is a national centre of expertise in digital information management, based at the University of Bath. UKOLN is funded by the JISC.
W3C Standards for Contacts and Calenders
Posted by Brian Kelly (UK Web Focus) on 27 December 2010
I have to admit that I thought that standards for contacts and calendar entries had been established ages ago. However the W3C’s Device APIs and Policy Working Group has been set up in order to “create client-side APIs that enable the development of Web Applications and Web Widgets that interact with devices services such as Calendar, Contacts, Camera, etc.“
A working draft of the Contacts API was published on 9 December 2010. As described in the W3C Newsletter:
“This specification defines the concept of a user’s unified address book – where address book data may be sourced from a plurality of sources – both online and locally. This specification then defines the interfaces on which third party applications can access a user’s unified address book, with explicit user permission and filtering. The focus of this data sharing is on making the user aware of the data that they will share and putting them at the center of the data sharing process; free to select both the extent to which they share their address book information and the ability to restrict which pieces of information related to which contact gets shared.“
Other work in the area includes the following draft specification:
- The Calendar API which was published back in February 2010.
- HTML Media Capture which was published in September 2010.
- Media Capture API (programmatic access to camera/microphone) which was published in September 2010.
- Messaging (SMS, MMS, emails) which was published in August 2010.
- Systems info and events (CPU, network, etc.) which was published in February 2010.
- Permissions for Device API Access which was published in October 2010.
- Gallery API which was published in November 2010.
- Application Launcher API which was published in November 2010.
Note that the URIs for the latest version of the a number of these draft specifications seem misleading. For example the URI for the Calendar API is stated as being http://www.w3.org/TR/calendar-api/ though this link is currently broken, with the resource actually hosted on the W3C’s development server at http://dev.w3.org/2009/dap/calendar/. Similarly the URL for The Application Launcher API is stated as being http://www.w3.org/TR/app-launcher/ though this link is currently broken, with the resource actually hosted on the W3C’s development server at http://dev.w3.org/2009/dap/app-launcher/. This may be because these are editor’s draft and the URIs for the published versions are place-holders – but for me this is an error, and one that is surprising for the W3C which places great emphasis on the importance of functioning URIs.
Tweets that mention W3C Standards for Contacts and Calenders: I have to admit that I thought that standards for contacts and calenda... -- Topsy.com said
[...] This post was mentioned on Twitter by nancyrubin, Brian Kelly. Brian Kelly said: W3C Standards for Contacts and Calenders: I have to admit that I thought that standards for contacts and calenda… http://bit.ly/dEfWoa [...]
Scott Wilson said
These are JavaScript APIs rather than data model standards – largely derived from existing built-in APIs in mobile phones for accessing the address book and calendar functions. The actual data structures for the most part follow Portable Contacts/VCard/iCalendar formats.
These particular specs are evolving quickly as they have to keep pace with the sorts of features handset manufacturers are adding to their devices, and the sorts of native APIs being added to phone OS’s.
Definitely worth tracking if you’re developing mobile applications – basically, if you know you want to play with a calendar file, and its in iCal, and you know its URL, then you can use iCal. If you’re deploying an app that wants access to the current viewer’s calendar entries, wherever they might be stored, then you’ll need to use these APIs.
Media capture is really, really cool though… especially the W3C Note based on Ericsson’s experimental direct video capture in Firefox (videoconferencing without Flash!)
Anthony Leonard said
Media capture is really, really cool though… especially the W3C Note based on Ericsson’s experimental direct video capture in Firefox (videoconferencing without Flash!)
Very interesting. I’m sure Google would be happy to adopt this for GTalk and ditch Flash for web video conferencing in the long run, so they might drive this also…