W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2010

Draft Minutes F2F Day 2, 2010-03-17

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Thu, 18 Mar 2010 04:17:13 -0400
Message-Id: <89ACF6E3-1FD0-4A13-B5DF-E0F1D7C81FB3@nokia.com>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
Attached are Draft Minutes F2F Day 2, 2010-03-17, HTML follows text.

regards, Frederick

Frederick Hirsch
Nokia




# Device APIs and Policy Working Group F2F Day 2

## 17 Mar 2010

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    RuthVazquez, LauraA, Dominique_Hazael-Massieux, Marco_Marengo,
Claes_Nilsson, Kangchan_Lee, Anssi_Kostiainen, Aurelien_Guillou,
Frederick_Hirsch, Ingmar_Kliche, Johnson_Wang, Ruth_Vazquez, Ilkka_Oksanen,
DanielColoma, Jesus_Martin, bryan_sullivan, John_Morris, Alissa_Cooper

Regrets


Chair

    Robin, Frederick

Scribe

    Aurelien

## Contents

  * [Topics][5]

    1. [System Info API][6]

    2. [Capture API][7]

    3. [Contacts API][8]

    4. [File Writer][9]

    5. [Next F2F meeting][10]

  * [Summary of Action Items][11]

* * *

<trackbot> Date: 17 March 2010

<dom> scribenick: LauraA

### System Info API

maxf: 2 lists of issues

... no much changed since first plublic draft

... 2 issues: one related to thresholds

other about maaping to DCO

<dom> [Sys Info API][12]

scribe: difficulties mapping to DCO (Delivery Content Ontology)

bryan: aligning to DCO is a good thing, making sure we are not fragmenting
further within W3C

... not complete with what I wanted to contribute with regards to DCO

maxf: open to modify set of properties

... do we really want codex (?) as properties?, do we want camera properties?
etc

... open to people's views on this

... we can just follow the DCO but it's missing fundamental properties

bryan: DCO is a work in development itself

<dom> [I note that SysInfo (probably through ReSpec links to an old version of
the DCO spec (2008 instead of 2009)

<dom> ]

bryan: UWA is trying to bring it to last call

... defining set of properties and defining access to those properties are
different questions

maxf: encourage people to have a look at the set of properties and check if
there's something missing

... there is a table at the end of the doc, in the appendices

<dom> [I've updated the ref to DCO in ReSpec]

<dom> [Sys Info API][12]

bryan: will help max fill out this table

<dom> **ACTION:** Bryan to provide input on DCO mapping for SysInfo [recorded
in [http://www.w3.org/2010/03/17-dap-minutes.html#action01][13]]

<trackbot> Created ACTION-116 - Provide input on DCO mapping for SysInfo [on
Bryan Sullivan - due 2010-03-24].

Wonsuk: benefit of mapping to DCO

maxf: DCO is a W3C spec, makes sense to make them compatible

... just mapping properties between sys info and DCO is simple, what is
difficult is to make them work, dealing with numeral properties:

... how do you access several batteries? givevn that DCO doesn't define
multiplicity

... 3rd issue: threshold

... problem is if you have CPU and have a watch object, if you specify a
threshold it's obcious that is applies to that

but in the case of Network, how do you know what the threshold applies to?

scribe: several properties: download BW and upload BW, which one does the
threshold apply to?

... because of minimisation (privacy), you could change your get function to
pass not only the property name but also the attribute name

... not decided which solution is best

<RuthVazquez> I am!

dom: when you have two dynamic values, you need to specify to which value the
threshold applies

Claes: problem with extensability

darobin: not necessarily, that's an implementation question

bsulliva: basic problem is: how do I watch a specific property?

maxf: what I suggest the either you specify a threshold and a target, or just
specify the target and not the threshold

dom: you need to highlight which of the properties are "watchable"

maxf: that's correct

<dom> **ACTION:** maxf to update sysinfo with the addition of watch/threshold
targets (and watchable attributes) [recorded in [http://www.w3.org/2010/03/17
-dap-minutes.html#action02][14]]

<trackbot> Created ACTION-117 - Update sysinfo with the addition of
watch/threshold targets (and watchable attributes) [on Max Froumentin - due
2010-03-24].

maxf: happy to go through the document and issues

... 1st issue: reuse DCO's base URI when applicable?

dom: UWA is currently out of charter

bsulliva: go forward and define a set of properties within DAP that make sense
and let UWA take care of them

maxf: 2nd issue: related to threshold, already solved

<dom> [Raised issues on SysInfo in Tracker][15]

maxf: 3rd issue:section 4.9 Audio and Video Codecs: Those properties could be
replaced by an array of DOMString in VideoCodec. The reason they are currently
defined as a separate property is that we may add specific fields later. But
is that ever going to be necessary?

<dom> **ACTION:** maxf to get rid of the empty interfaces and replace them
with the generic SystemProperty in SysInfo [recorded in
[http://www.w3.org/2010/03/17-dap-minutes.html#action03][16]]

<trackbot> Created ACTION-118 - Get rid of the empty interfaces and replace
them with the generic SystemProperty in SysInfo [on Max Froumentin - due
2010-03-24].

maxf: 4th issue, 4.11 Output Devices section: Do we need information about
active devices, e.g. in order to be able to see which screen is currently
being in use, or to control which set of speakers should be activated? If so
how do we specify it? Through an "active" flag on each device (hard to watch),
or through a pointer (e.g. currentDisplay in OutputDevices) which would mean
only one device is active at a time, which might not always be correct in
cases like

bsulliva: question is how to you model the state of things

... first thing to check is if it is Supported, is it Present and then is it
Available

maxf: question is how in practice to you put them in an interface, do you need
an Active array, Available array etc?

... I will take an action to write up both alternatives on how to define
availability so that the group can make a decision

<dom> **ACTION:** maxf to write up both alternatives on how to define
availability of multiple properties (e.g. Network, output devices) in SysIno
[recorded in [http://www.w3.org/2010/03/17-dap-minutes.html#action04][17]]

<trackbot> Created ACTION-119 - Write up both alternatives on how to define
availability of multiple properties (e.g. Network, output devices) in SysIno
[on Max Froumentin - due 2010-03-24].

maxf: 6th issue, section 4.11, constants defining device orientation: Are we
being short-sighted in only listing four orientations? Would it make sense to
have it be an angle, except that in most cases it would only change in 90°
increments?

drogersuk: there can be plenty of cases where you want to rotate more than 90°

... don't mind having constants, my concern is that we wouldn't be able to set
the angle to 31° for example, you are preventing an implementation there

bsulliva: let's take the use case where we have an accelerometer API

... do we want to change the screen orientation or the widget orientation?

... we want to control the presentation of the widget

<dom> ISSUE-59?

<trackbot> ISSUE-59 -- SysInfo: make minFrequency and maxFrequency optional --
RAISED

<trackbot> [http://www.w3.org/2009/dap/track/issues/59][18]

<dom> ISSUE-60?

<trackbot> ISSUE-60 -- orientation, acceleration compass in System Information
-- RAISED

<trackbot> [http://www.w3.org/2009/dap/track/issues/60][19]

<dom> ISSUE-64?

<trackbot> ISSUE-64 -- "Generic" sensors may permit discovering sensitive
information -- RAISED

<trackbot> [http://www.w3.org/2009/dap/track/issues/64][20]

<dom> ISSUE-76?

<trackbot> ISSUE-76 -- Available/Preferred Networks in sysinfo -- RAISED

<trackbot> [http://www.w3.org/2009/dap/track/issues/76][21]

<dom> close ISSUE-59

<trackbot> ISSUE-59 SysInfo: make minFrequency and maxFrequency optional
closed

<dom> ISSUE-59: overtaken by more recent edits

<trackbot> ISSUE-59 SysInfo: make minFrequency and maxFrequency optional notes
added

<dom> close ISSUE-60

<trackbot> ISSUE-60 orientation, acceleration compass in System Information
closed

<dom> ISSUE-60: overtaken by events

<trackbot> ISSUE-60 orientation, acceleration compass in System Information
notes added

<bsulliva> Link to DPE spec: [http://www.openmobilealliance.org/Technical/rele
ase_program/dpe_V1_0.aspx][22], where "Table 6 14: Policy Types and
Parameters" includes the set of "watch" method options I suggest we align with
the SysInfo API

<dom> (I'm linking maxf's ACTION-115 on warning re fingerprinting to tlr's
ISSUE-64 on generic sensors leaking sensitive info)

### Capture API

<dom> [Capture API editors draft][23]

ilkka: pretty simple API in general

... only one recent update

... commited the new version on Monday night

... there are 3 interfaces for capturing images, video and audio

... 3 attributes describe which are the supported formats

... success CB and error CB for the 3 interfaces

AnsiiK: in the first draft we had 3 methods for image, video and audio
capturing

... we can make it just one method call

darobin: we should do whatever is simplest for us to define

AnsiiK: just thought of another way of doing this, having a common capture
method and just pass the media data object as part of the options

darobin: proposal A is shorter

AnsiiK: that is what is currently in the spec

... do we have consensus?

<richt> Is it worth/possible allowing both of these patterns (JS method
overloading): captureImage(success, error, options) AND captureImage(success,
options)

<richt> ...and captureImage(success) and captureImage(success, error) ???

ilkka: in the latest update added text to describe access the camera, section
5. Capture Input selection

... section 5.1 is informative an explains what is already possible today, as
a hint to implementors

AnssiK: "explain

... "explain an example"

darobin: this image/example should go in the spec

AnssiK: 5.2 is a third option to use File picker

... Robin is the originator of this idea

ilkka: (section 5.2) viewFinder interface that inherits from file

(Robin goes through the example in section 5.2)

ingmar: the input element at the beginning of the example is not needed

darobin: dom has already removed it

AnssiK: are we happy that we have these 3 cases (native interface, file picker
and viewfiner interface) in one API?

darobin: yes, that's ok

dom: we don't want to enforce it, we want to show different ways of doing it

<dom> -> [http://www.mediawiki.org/wiki/Mobile_browser_testing/iPhone#Unsuppor
ted_Technologies.5B7.5D][24] "Safari on iPhone does not support <input
type="file"> elements; these events get disabled by Safari."

richt: would it be possible to have a media data file object?

darobin: we should inherit from File

... we might want to change the name to ViewFinder

<dom> dom: not sure if we should inherit from File, or create a MediaData
object out of a the blob

<dom> robin: let's go with inheritance and log an issue on the spec:

<dom> s/sepc/spec/

[http://demos.hacks.mozilla.org/openweb/FileAPI/][25]

richt: this relates to other APIs as well

AnssiK: section 3.1.2: it can be useful to programmaticaly control the length
of the video, for example

richt: are error CB nullable?

darobin: error CBs should be nullable

fhirsch: It may be worth having one separate doc with reqs for all APIs

... move the reqs of the individual docs into the currently existing reqs doc

<dom> PROPOSED RESOLUTION: Requirements and use cases are migrated back from
individual APIs to the APIs requirement document

darobin: editors of individual API specs should do this

**RESOLUTION: Requirements and use cases are migrated back from individual
APIs to the APIs requirement document**

ingmar: regarding the ViewFinder case, do we need another entrance point for
the case when the user does not want to click everytime he wants to use the
camera?

darobin: we might want to look at what BONDI does

... "additional entry points for trusted environments"

richt: overloading, is there a better way to describe overloading other than
what is currently done?

darobin: we could put everything in the options

<dom> (this relates to ISSUE-55)

richt: I like that

<dom> ISSUE-55?

<trackbot> ISSUE-55 -- Should we use object literals in place of positional
parameters and if so when? -- RAISED

<trackbot> [http://www.w3.org/2009/dap/track/issues/55][26]

darobin: this makes overloading simpler, despite being more verbose to write

dom: this is a nice thing to define, but it diverts from the Geo API

darobin: this would work fine with REST

... proposal: we put it in the spec and see how people react

<dom> ISSUE-55: sounds like object literals would be fairly nice in terms of
specification, but would bring differences with the existing APIs (e.g.
geolocation)

<trackbot> ISSUE-55 Should we use object literals in place of positional
parameters and if so when? notes added

<dom> **ACTION:** Robin to check with Geolocation WG re choice of object
literals vs positional parameters in geo API [recorded in
[http://www.w3.org/2010/03/17-dap-minutes.html#action05][27]]

<trackbot> Created ACTION-120 - Check with Geolocation WG re choice of object
literals vs positional parameters in geo API [on Robin Berjon - due
2010-03-24].

<darobin> **ACTION:** Robin to do send out a CfC for Capture as soon as the
updates are done [recorded in [http://www.w3.org/2010/03/17-dap-
minutes.html#action06][28]]

<trackbot> Created ACTION-121 - Do send out a CfC for Capture as soon as the
updates are done [on Robin Berjon - due 2010-03-24].

<jmorris> is there an audio connection into the room?

<darobin> agenda updates:

<darobin> session 2-7 is now FileWriter

<darobin> session 3-5 is now Gallery, and F2F

<darobin> RuthVazquez, jmorris: we're setting up Skype

<RuthVazquez> ok, thanx

<fjh> by default contacts returns single contact object unless mulitple option
set

<fjh> this is a change in line with minimization

<dom> ScribeNick: aguillou

### Contacts API

<dom> Scribe: Aurelien

<scribe> TOPIC : Contact API (R. Tibbett)

List of the issues leveraged on Contact API

Section 4.2 - find() method

Specified as a DOM String array in the fileds

<dom> [Contacts API editors draft][29]

An example is available in section "create a new contact".

Do we want to move on in an Object "style" instead of an classical DOMString
array ?

if we just want to know only the ZIP code, how does it works ?

fields mapping need to be done to check the values specified in parameters

richt: methods are following the REST style way to define functions (getters
and setters)

darobin: Can we pass a object as a value in parameter and then updated in the
functions ?

richt: 2nd issue - data format to use in the attributes

<RuthVazquez> ups, yes Susana is Ruth... at least I'm muted

richt: Portable Context for ex. is compatible with vCard

<RuthVazquez> I just though Zakim was asking again, I don't know my handle

<alissa> I'm on the call

richt: we chould think about a portable format concerning the contact
attributes

dom: we could have a minimum mandatory subset of attributes

richt: we need to be aligned with the vCard format

... may be a subset of vCard is enough for the Contact attributes ...

<alissa> I will see the vcard people at IETF next week -- is there anything
useful to ask them? Perhaps if others have profiled vcard before and how the
subsetting worked out?

Annsik: ... using such vCard subset will be easier for data mapping and
portability

<alissa> ok

<alissa> can't hear bryan

bsulliva: the address book of the SIMcard is based on vCard (3GPP)

<alissa> ok, thanks aguillou

richt: 3rd Issue - Phishing against an API ?

<richt> richt: phishing against error codes

darobin: ... it's not really an issue....

richt: 4th Issue - Sedtion 6. Note - Pattern Matching in contact list

fjh: Is it equivalent to a regular expression ?

<jmorris> So this means that if I ONLY want to share "Robert" I could not
avoid also sharing "Roberta" ?

<darobin> we have a use case: [http://xkcd.com/208/][30]

Richt: Isit partial matching or whole word matching ?

<dom> jmorris, you could avoid sharing by not selecting it in the intermediary
screen presented by the UA

<fjh> can match string in middle of name without regular expressions

<jmorris> thanks

<darobin> s/chose/choose/

bsulliva: how easy is it to use such filter feature ?

<fjh> topic of internationalization can be an issue, e.g. in korea searching
only by consonant

dom: text search is complicated in term of implementation.

<darobin> **ACTION:** Robin to talk to I18N about text search in Contacts —
can we do it right (simply), or do we leave it to be implementation-dependent
[recorded in [http://www.w3.org/2010/03/17-dap-minutes.html#action07][31]]

<trackbot> Created ACTION-122 - Talk to I18N about text search in Contacts —
can we do it right (simply), or do we leave it to be implementation-dependent
[on Robin Berjon - due 2010-03-24].

dom: we should pass a string to the UA and then get the results back

... do we need to specify that it's a substring matching ?

... we should be explicit about the search behavior (substring matching or
not).

<richt> richt: do we need to be specific on the encoding for i18n: e.g.
input/output must be UTF8 encoded.

<dom> dom: we probably don't need to say anything about this

<richt> darobin: we don't need to be specific. JS uses UTF16 internally.

darobin: string transcoding in JS

richt: service ID attribute in 4.2

... default behavior in the serviceID is not specified ?

bsulliva: contacts could be on the SIM card or on Google, what's the default
behaviour ?

dom: not sure we have enough use cases where we use the Service ID parameter

richt: in Facebook, your contacts are represented from an URI

... ServiceID is useful when we need to address to several Contacts lists (SIM
card, FaceBook, Google, etc.)

bsulliva: we need to specify more clearly the use cases (device, SIM,
network). And then, we can check if it's a good solution

dom: adressing these use cases are quiet complex.

darobin: ... may we can put the use cases in a separate doc.

... merge all your address books from Web providers and your SIM card

<fjh> discussion of address book api allowing functionality like merge etc

bsulliva: if we say it works only for device and SIM cards, it's quiet simple.

richt: ... but if we include Web providers, it starts to complicated

bsulliva: how those API use of specifi address book ?

<darobin> **ACTION:** Bryan to make a concrete proposal how Contacts could
support use of specific address books [recorded in
[http://www.w3.org/2010/03/17-dap-minutes.html#action08][32]]

<trackbot> Created ACTION-123 - Make a concrete proposal how Contacts could
support use of specific address books [on Bryan Sullivan - due 2010-03-24].

dom: we need to have a better idea of the costs of supporting these features
(network, SIM, etc.)

bsulliva: we need more description of the use cases

richt: Security and Privacy Issues

... discussions concerning the UIs.

<darobin> **ACTION:** richard to create a mockup of the contacts UI for
contact picker, based on previous mailing list discussion of use cases
[recorded in [http://www.w3.org/2010/03/17-dap-minutes.html#action09][33]]

<trackbot> Created ACTION-124 - Create a mockup of the contacts UI for contact
picker, based on previous mailing list discussion of use cases [on Richard
Tibbett - due 2010-03-24].

richt: ...other questions about the Contact API ?

darobin: ... when the changes will be done ?

richt: around end of April...

... it will takes couple of weeks.

dom: we chould add REST considerations

<darobin> **ACTION:** Richard to fold in Contacts changes (and when done ping
Robin to start a CfC) [recorded in [http://www.w3.org/2010/03/17-dap-
minutes.html#action10][34]]

<trackbot> Created ACTION-125 - Fold in Contacts changes (and when done ping
Robin to start a CfC) [on Richard Tibbett - due 2010-03-24].

<darobin> action-125

<darobin> action-125?

<trackbot> ACTION-125 -- Richard Tibbett to fold in Contacts changes (and when
done ping Robin to start a CfC) -- due 2010-03-24 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/125][35]

dom: what the plan for the last call in June ?

darobin: we need to have 3-4 specs for the last call.

<jmorris> can you briefly summarize the expected agenda for the afternoon?

### File Writer

<darobin> [FileWriter API editors draft][36]

darobin: TOPIC - File API Writer

<jmorris> thanks

darobin: a lot of discussions around the File Writer API

... Section 2.1 - File Writer API JS example

... Do we keep the Automatic Line ending issue ?

bsulliva: does the platform caould modify the CR ?

darobin: it's a kind of encoding issue,

... there's a Sync. version of the File Writer API

... Section 7 is completely wrong.

... the use of the "input" element will prompt a doanload dialog.

... We need to create another method, instead of using the "input" method

<dom> PROPOSED RESOLUTION: Replace <input type="saveas"> by a JavaScript
method such as navigator.saveFile()

<dom> **ACTION:** Robin to modify FileWriter to add the saveFile() method
[recorded in [http://www.w3.org/2010/03/17-dap-minutes.html#action11][37]]

<trackbot> Created ACTION-126 - Modify FileWriter to add the saveFile() method
[on Robin Berjon - due 2010-03-24].

ilkka: how we know the end of the file if we don't have a Read access ?

**RESOLUTION: Replace <input type="saveas"> by a JavaScript method such as
navigator.saveFile()**

darobin: ... we could do that with the Seek method

ilkka: we need to check that (use of the length attribute) in the File Writer
API

**RESOLUTION: We publish FileWRiter as FPWD once new fileWriter entry point is
added**

<dom> PROPOSED RESOLUTION: split privacy out of policy-reqs into its own
document

<dom> PROPOSED RESOLUTION: split privacy out of policy-reqs into its own
document and publish privacy-reqs soon

<dom> jmorris, any feedback on the proposed resolution above?

**RESOLUTION: split privacy out of policy-reqs into its own document and
publish privacy-reqs soon**

<dom> **ACTION:** Frederick to prepare privacy-reqs out of policy-reqs for a
call for consensus for FPWD [recorded in [http://www.w3.org/2010/03/17-dap-
minutes.html#action12][38]]

<trackbot> Created ACTION-127 - Prepare privacy-reqs out of policy-reqs for a
call for consensus for FPWD [on Frederick Hirsch - due 2010-03-24].

darobin: TOPIC - Calendar API

Usage of the Lunar Calendar System in Korea

<dom> [Lunar Calendar in Wikipedia][39]

<dom> [Input on Lunar Calendar system for device APIs][40]

Kangchan: we can use several calendar systems: solar and lunar for ex.

<darobin> -> an implementation of a converter
[http://cpansearch.perl.org/src/AERO/Date-Korean-0.0.2/lib/Date/Korean.pm][41]

Kangchan: Examples of Lunar / Solar Calendar UIs implemented on mobile devices

wonsuk: In korea, we can have the 2 calendar systems on a single calendar.

Kangchan: [http://calendar.naver.com/][42]

... Use Case 1 - a Web Application would like to access the device calendar

... Use Case 2 - a user would like to change a calendar appointment

<darobin> **ACTION:** Robin to contact I18N about other potential calendaring
issues [recorded in [http://www.w3.org/2010/03/17-dap-
minutes.html#action13][43]]

<trackbot> Created ACTION-128 - Contact I18N about other potential calendaring
issues [on Robin Berjon - due 2010-03-24].

<fjh> is this really different than time zones, in an abstract sense?

Kangchan: ...Use Case 5 - A web application would like to sync. with Web
Portal

<dom> [Calendar API Editors draft][44]

Kangchan: Lunar Calendar System is not used for ex. in the pictures taken by
the cameras

... Proposal to support Lunar Calendar System to DAP

... an attribute is added to the interface CalendarEventProperties {...
lunisolar; 0=solar(default); 1=lunar}

dom: we might have interroperability problems between calendars....

<dom> dom: export to icalendar might become problematic with lunar-solar
calendars

<dom> "iCalendar's calendar is also not compatible with some non-Gregorian

<dom> Gregorian

<dom> Gregorian might refer to:*Named for Pope Gregory I:**Gregorian
chant**Brotherhood of Saint Gregory*Gregorian reform *Named for Pope Gregory
XIII**Gregorian calendar**Gregorian University, Rome...

<dom> calendars such as the lunar calendars

<dom> Lunar calendar

<dom> A lunar calendar is a calendar that is based on cycles of the moon
phase. The only widely used purely lunar calendar is the Islamic calendar or
Hijri calendar, whose year always consists of 12 lunar months...

<dom> used in Israel

<dom> Israel

<dom> Israel officially the State of Israel , is a developed state in Western
Asia located on the eastern shore of the Mediterranean Sea. It borders Lebanon
in the north, Syria in the northeast, Jordan in the east, and Egypt on the
southwest, and contains geographically diverse features within its...

<dom> or Saudi Arabia

<dom> Saudi Arabia

<dom> Saudi Arabia , is an Arab country and the largest country of the Arabian
Peninsula. It is bordered by Jordan on the northwest, Iraq on the north and
northeast, Kuwait, Qatar, Bahrain, and the United Arab Emirates on the east,
Oman on the southeast, and Yemen on the south...

<dom> . Although there exist one-to-one mappings between Gregorian and many
other calendar scales, the lack of defined CALSCALE values for those calendars
and limitations in various date fields can make native support impossible. For
example the Hebrew calendar

<dom> Hebrew calendar

<dom> The Hebrew calendar or Jewish calendar is a lunisolar calendar used by
Jews, and in recent decades, by a growing number of Christians...

<dom> year may contain either 12 or 13 months, and the Japanese

<dom> Japanese era name

<dom> The Japanese era calendar scheme is a common calendar scheme used in
Japan, which identifies a year by the combination of the and the year number
within the era...

<dom> Emperor-based calendar scale contains many eras."

<dom> [http://www.absoluteastronomy.com/topics/ICalendar][45]

<dom> ISSUE: Can we support lunasolar calendars in the calendar API?

<trackbot> Created ISSUE-80 - Can we support lunasolar calendars in the
calendar API? ; please complete additional details at
[http://www.w3.org/2009/dap/track/issues/80/edit][46] .

richt: iCalendar / vCard must support Lunar calendar via conversion to
Solar... need to check that

darobin: we need to store a flag somewhere in the iCalendar to know if it's a
lunar / solar calendar

richt: do we need to maintain this lunar / solar information ?

darobin: ...or we can use a specfic convertion method lunar<->solar... not
sure it will work.

... we need to check with the I18N WG if there're works already done around
Lunar / Solar calendar conversions

AnssiK: and what for the Maya Calendar ?...

richt: TOPIC Calendar API

... which date format to use ?

... we can use JS specific date format

darobin: we must use a Date object.

... HTML 5 uses a Date object.

<dom> [ECMAscript 5 spec][47]

darobin: .... we should do the same as HTML 5.

<dom> [Date object defined page 165]

<darobin> **ACTION:** richard to figure out how to specify TimeZonedDate
[recorded in [http://www.w3.org/2010/03/17-dap-minutes.html#action14][48]]

<trackbot> Created ACTION-129 - Figure out how to specify TimeZonedDate [on
Richard Tibbett - due 2010-03-24].

<darobin> ISSUE: How to represent dates? ES has Date but with no TZ
information; using strings is less than ideal; do we have to create a Web
Dates specification?

<trackbot> Created ISSUE-81 - How to represent dates? ES has Date but with no
TZ information; using strings is less than ideal; do we have to create a Web
Dates specification? ; please complete additional details at
[http://www.w3.org/2009/dap/track/issues/81/edit][49] .

richt: we can use for ex. a getDate() method on the Date object in order to
retrieve the local time.

... a proposal is to use a subset of iCalendar in the events, but is it enough
?

dom: we should be iCalendar compatible.

<AnssiK> [http://lists.w3.org/Archives/Public/public-device-
apis/2009Nov/0016.html][50]

<AnssiK> discussion on how to pass in times for calendar events above

richt: ex. of use of calendar events: Weekly, Monthly, etc.

... [http://lists.w3.org/Archives/Public/public-device-
apis/2010Mar/0130.html][51]

... we need to be sure that developers will use Calendar Events in the right
way.

... the challenge in the Calendar API is to keep it simple as possible...

<dom> PROPOSED RESOLUTION: Calendar API FPWD is delayed until recurrence is
better handled

**RESOLUTION: Calendar API FPWD is delayed until recurrence is better
handled**

<dom> s/<dom> RESOLUTION/<aguillou> RESOLUTION/

richt: there're still some issues in the calendar API that need to be
discussed (iCalendar, Calendar events)

... Calendar Events mangement with the Time zones...

AnnsiK: do we need to use UTC time, floating time, time zones ?

richt: the local time is linked to a specific time zone,

<fjhn> **ACTION:** richt to propose changes to calendar specification to
address privacy minimization [recorded in [http://www.w3.org/2010/03/17-dap-
minutes.html#action15][52]]

<trackbot> Created ACTION-130 - Propose changes to calendar specification to
address privacy minimization [on Richard Tibbett - due 2010-03-24].

darobin: F2F location talks

### Next F2F meeting

darobin: we need to decide on when and where we will meet for the F2F

... we could meet in Sept. instead of July. Invitation from ETRI to meet in
Korea.

... ... last week of June should probably work.

... June 14-16: Helsinki / St Petersburg

... Nov wk 1 : TPAC Lyon

... Feb-Mar 2011 : Korea

... June 2011 - St Petersburg

June 14-16 : OMTP London ?

<dom> **ACTION:** Dom to set up poll for next F2F around mid June (14-18) or
first week of July, in either Helskinki, London, Seoul, Madrid [recorded in
[http://www.w3.org/2010/03/17-dap-minutes.html#action16][53]]

<trackbot> Created ACTION-131 - Set up poll for next F2F around mid June
(14-18) or first week of July, in either Helskinki, London, Seoul, Madrid [on
Dominique Hazaël-Massieux - due 2010-03-24].

<darobin> RESOLUTION: DAP will meet at TPAC

<ilkka> dinner: [http://maps.google.com/maps?f=d&source=s_d&saddr=Italsk%C3%A1
&daddr=Na+boji%C5%A1ti+12][54],+120+00+Praha+2,+Praha,+Czech+Republic+(Hostine
c+U+Kalicha)&hl=en&geocode=Fbs2_AIdoVbcAA%3BFW0P_AIdlCfcAC

<dom> [http://www.ukalicha.cz/shop/index.php?lang=EN][55]

<dom> [http://www.gastroinfo.cz/pivodum/][56]

<ilkka> yes, foget my link

## Summary of Action Items

**[NEW]** **ACTION:** Bryan to make a concrete proposal how Contacts could
support use of specific address books [recorded in
[http://www.w3.org/2010/03/17-dap-minutes.html#action08][32]]

**[NEW]** **ACTION:** Bryan to provide input on DCO mapping for SysInfo
[recorded in [http://www.w3.org/2010/03/17-dap-minutes.html#action01][13]]

**[NEW]** **ACTION:** Dom to set up poll for next F2F around mid June (14-18)
or first week of July, in either Helskinki, London, Seoul, Madrid [recorded in
[http://www.w3.org/2010/03/17-dap-minutes.html#action16][53]]

**[NEW]** **ACTION:** Frederick to prepare privacy-reqs out of policy-reqs for
a call for consensus for FPWD [recorded in [http://www.w3.org/2010/03/17-dap-
minutes.html#action12][38]]

**[NEW]** **ACTION:** maxf to get rid of the empty interfaces and replace them
with the generic SystemProperty in SysInfo [recorded in
[http://www.w3.org/2010/03/17-dap-minutes.html#action03][16]]

**[NEW]** **ACTION:** maxf to update sysinfo with the addition of
watch/threshold targets (and watchable attributes) [recorded in
[http://www.w3.org/2010/03/17-dap-minutes.html#action02][14]]

**[NEW]** **ACTION:** maxf to write up both alternatives on how to define
availability of multiple properties (e.g. Network, output devices) in SysIno
[recorded in [http://www.w3.org/2010/03/17-dap-minutes.html#action04][17]]

**[NEW]** **ACTION:** richard to create a mockup of the contacts UI for
contact picker, based on previous mailing list discussion of use cases
[recorded in [http://www.w3.org/2010/03/17-dap-minutes.html#action09][33]]

**[NEW]** **ACTION:** richard to figure out how to specify TimeZonedDate
[recorded in [http://www.w3.org/2010/03/17-dap-minutes.html#action14][48]]

**[NEW]** **ACTION:** Richard to fold in Contacts changes (and when done ping
Robin to start a CfC) [recorded in [http://www.w3.org/2010/03/17-dap-
minutes.html#action10][34]]

**[NEW]** **ACTION:** richt to propose changes to calendar specification to
address privacy minimization [recorded in [http://www.w3.org/2010/03/17-dap-
minutes.html#action15][52]]

**[NEW]** **ACTION:** Robin to check with Geolocation WG re choice of object
literals vs positional parameters in geo API [recorded in
[http://www.w3.org/2010/03/17-dap-minutes.html#action05][27]]

**[NEW]** **ACTION:** Robin to contact I18N about other potential calendaring
issues [recorded in [http://www.w3.org/2010/03/17-dap-
minutes.html#action13][43]]

**[NEW]** **ACTION:** Robin to modify FileWriter to add the saveFile() method
[recorded in [http://www.w3.org/2010/03/17-dap-minutes.html#action11][37]]

**[NEW]** **ACTION:** Robin to talk to I18N about text search in Contacts —
can we do it right (simply), or do we leave it to be implementation-dependent
[recorded in [http://www.w3.org/2010/03/17-dap-minutes.html#action07][31]]


**[DONE]** **ACTION:** Robin to do send out a CfC for Capture as soon as the
updates are [recorded in [http://www.w3.org/2010/03/17-dap-
minutes.html#action06][28]]


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][57] version 1.135 ([CVS
log][58])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Mar/0079.html;

   [4]: http://www.w3.org/2010/03/17-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #ActionSummary

   [12]: http://dev.w3.org/2009/dap/system-info/

   [13]: http://www.w3.org/2010/03/17-dap-minutes.html#action01

   [14]: http://www.w3.org/2010/03/17-dap-minutes.html#action02

   [15]: http://www.w3.org/2009/dap/track/products/8

   [16]: http://www.w3.org/2010/03/17-dap-minutes.html#action03

   [17]: http://www.w3.org/2010/03/17-dap-minutes.html#action04

   [18]: http://www.w3.org/2009/dap/track/issues/59

   [19]: http://www.w3.org/2009/dap/track/issues/60

   [20]: http://www.w3.org/2009/dap/track/issues/64

   [21]: http://www.w3.org/2009/dap/track/issues/76

   [22]:
http://www.openmobilealliance.org/Technical/release_program/dpe_V1_0.aspx

   [23]: http://dev.w3.org/2009/dap/camera/

   [24]: http://www.mediawiki.org/wiki/Mobile_browser_testing/iPhone#Unsupport
ed_Technologies.5B7.5D

   [25]: http://demos.hacks.mozilla.org/openweb/FileAPI/

   [26]: http://www.w3.org/2009/dap/track/issues/55

   [27]: http://www.w3.org/2010/03/17-dap-minutes.html#action05

   [28]: http://www.w3.org/2010/03/17-dap-minutes.html#action06

   [29]: http://dev.w3.org/2009/dap/contacts/

   [30]: http://xkcd.com/208/

   [31]: http://www.w3.org/2010/03/17-dap-minutes.html#action07

   [32]: http://www.w3.org/2010/03/17-dap-minutes.html#action08

   [33]: http://www.w3.org/2010/03/17-dap-minutes.html#action09

   [34]: http://www.w3.org/2010/03/17-dap-minutes.html#action10

   [35]: http://www.w3.org/2009/dap/track/actions/125

   [36]: http://dev.w3.org/2009/dap/file-system/file-writer.html

   [37]: http://www.w3.org/2010/03/17-dap-minutes.html#action11

   [38]: http://www.w3.org/2010/03/17-dap-minutes.html#action12

   [39]: http://en.wikipedia.org/wiki/Lunar_calendar

   [40]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Mar/0159.html

   [41]: http://cpansearch.perl.org/src/AERO/Date-
Korean-0.0.2/lib/Date/Korean.pm

   [42]: http://calendar.naver.com/

   [43]: http://www.w3.org/2010/03/17-dap-minutes.html#action13

   [44]: http://dev.w3.org/2009/dap/calendar/

   [45]: http://www.absoluteastronomy.com/topics/ICalendar

   [46]: http://www.w3.org/2009/dap/track/issues/80/edit

   [47]: http://www.ecma-international.org/publications/files/ECMA-
ST/ECMA-262.pdf

   [48]: http://www.w3.org/2010/03/17-dap-minutes.html#action14

   [49]: http://www.w3.org/2009/dap/track/issues/81/edit

   [50]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Nov/0016.html

   [51]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Mar/0130.html

   [52]: http://www.w3.org/2010/03/17-dap-minutes.html#action15

   [53]: http://www.w3.org/2010/03/17-dap-minutes.html#action16

   [54]: http://maps.google.com/maps?f=d&source=s_d&saddr=Italsk%C3%A1&daddr=N
a+boji%C5%A1ti+12

   [55]: http://www.ukalicha.cz/shop/index.php?lang=EN

   [56]: http://www.gastroinfo.cz/pivodum/

   [57]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [58]: http://dev.w3.org/cvsweb/2002/scribe/



Received on Thursday, 18 March 2010 08:18:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:07 GMT