See also: IRC log
<trackbot> Date: 23 September 2009
<brianleroux> hello =)
<brianleroux> I'm on the call as well.
<dtran> dtran is Dzung Tran
<marengo> marengo is Marco Marengo
<arve> zakim not picking up on people calling in?
<darobin> this is DAP
<brianleroux> the bridge is recursive echoing
<LauraArribas> Preset+ LauraArribas
<darobin> Scribe: marcin3
<darobin> Scribe: Marcin
<darobin> ScribeNick: marcin3
<darobin> Chair: Frederick, Robin
no changes to the agenda
<Bryan> +1425.214.aaee is Bryan
reminder to register to TPAC meeting and book the hotel
resolution: minutes approved
<darobin> ACTION: robin to link minutes from the group page [recorded in http://www.w3.org/2009/09/23-dap-minutes.html#action01]
<trackbot> Created ACTION-14 - Link minutes from the group page [on Robin Berjon - due 2009-09-30].
The list of editors was sent
Robin's reSpec.js to get more attention, reviewed. Robin welcomes feedback.
actions discussed, just a few actions are left
<trackbot> ISSUE-18 -- Determine security policy starting points for review and comparison -- RAISED
not many changes introduced within 1.01 as compared to 1.0
<fhirsch> Dom did earlier comparison
FH: questions to the policy
... do we want features and capabilities?
... BONDI has both
... hierarchies of the features
<dtran> Still unclear the differences
FH: discussion needed about features and capabilities
<Bryan> Bryan will help out there
<brianleroux> capability; something the device can do (has a camera). features: camera api
FH: any volunteers to compare capabilities and features?
<dtran> So for a certain client, that camera api might not be implemented because the client does not have the capability
<scribe> ACTION: Marcin to review/compare device capabilities and features [recorded in http://www.w3.org/2009/09/23-dap-minutes.html#action02]
<trackbot> Created ACTION-15 - Review/compare device capabilities and features [on Marcin Hanclik - due 2009-09-30].
<brianleroux> dtran: I think so yes
<darobin> ACTION: Bryan to help review/compare device capabilities and features [recorded in http://www.w3.org/2009/09/23-dap-minutes.html#action03]
<trackbot> Created ACTION-16 - Help review/compare device capabilities and features [on Bryan Sullivan - due 2009-09-30].
BS: Marcin and me may contributes
FH: requirements to be prepared for features/caps
<fhirsch> comparison should probably include Lewontin workshop paper as well Bondi 1.01 and Nokia submissions
FH: Marcos did some stuff about reputation, other suggestions are welcome
... the group is open to new suggestions
... please send anything what could help to the list
... Robin to continue with the APIs
RB: The initial requirements were provided on the list. Discussion points to be identified.
... Richard's input
<trackbot> ISSUE-13 -- Gathering requirements -- OPEN
<trackbot> ISSUE-7 -- Gathering requirements -- OPEN
RB: it is about messaging, coverage. Is it clearer, Richard?
RT: what is the concept of the ubiquitos Web?
... should telephony/SMS be included?
RB: ubiquitos means "it runs everywhere"
... screens in watches, urinals are also Web
<dtran> yes, telephony/SMS should be
RB: capabilities of the device are important
... ubiquitos and not capable do not necessarily clash
... the existing messaging proposals (Nokia, BONDI etc) may suggest want we need
... messaging must be able to address different transports, capabilities and related details
... emails need attachments, differences may suggest the design
BS: the goal of ubiquitos Web is to address potential environment, awareness, context
RB: Richard, will you be able to proceed for the next week
... Calendar API, issue-7
<trackbot> ISSUE-7 -- Gathering requirements - calendar -- OPEN
RT: some feedback provided
... a lot to be done on the high level
... should we support more than 1 calendars?
RB: there are pros and cons
... it should be clarified over email
... Arve has comments
... what does it mean to support iCalendar
Resolution: let's continue over email
<dtran> multiple calendars for family, work, play calendars
ABe to send comments
<trackbot> ISSUE-14 -- Gathering requirements -- OPEN
RB: the long list of requirements about NavigatorPlatform
TRAN: it stems from geolocation, I will send another email
RB: a good requirement would be to have: the interface must provide the information about battery level
... functional requirements to be provided
<scribe> ACTION: TRAN to provided more functional requirements [recorded in http://www.w3.org/2009/09/23-dap-minutes.html#action04]
<trackbot> Created ACTION-17 - Provided more functional requirements [on Dzung Tran - due 2009-09-30].
<crobiso1> crobiso1 is Clayne Robison
RB: does anyone want to take care of contact, FS?
<darobin> ACTION: Arve to review Contacts requirements [recorded in http://www.w3.org/2009/09/23-dap-minutes.html#action05]
<trackbot> Created ACTION-18 - Review Contacts requirements [on Arve Bersvendsen - due 2009-09-30].
<scribe> ACTION: Bryan Leroux to review contact, camera, file-system [recorded in http://www.w3.org/2009/09/23-dap-minutes.html#action06]
<trackbot> Created ACTION-19 - Leroux to review contact, camera, file-system [on Bryan Sullivan - due 2009-09-30].
<trackbot> ACTION-6 -- Robin Berjon to send a reminder about TPAC -- due 2009-09-09 -- CLOSED
<trackbot> ACTION-19 -- Bryan Sullivan to leroux to review contact, camera, file-system -- due 2009-09-30 -- OPEN
BS: I will be providing general comments
<trackbot> ISSUE-6 -- Gathering requirements -- OPEN
issue-6 is applauncher
ABe: my proposal is controversial
<darobin> ACTION: Marcin to send comments about Arve's requirements for ISSUE-6 [recorded in http://www.w3.org/2009/09/23-dap-minutes.html#action07]
<trackbot> Created ACTION-20 - Send comments about Arve's requirements for ISSUE-6 [on Marcin Hanclik - due 2009-09-30].
<darobin> ACTION: Bryan to send comments about Arve's requirements for ISSUE-6 [recorded in http://www.w3.org/2009/09/23-dap-minutes.html#action08]
<trackbot> Created ACTION-21 - Send comments about Arve's requirements for ISSUE-6 [on Bryan Sullivan - due 2009-09-30].
<trackbot> ISSUE-5 -- Gathering requirements -- OPEN
issue-5 is Application Configuration
Arve: we probably drop the AppConfig from the deliverables
MH: BONDI considers dropping AppConfig once A&E and Storage specs are ready
BS: we need some local storage. If it is HTML5 or widget context, it shall be enough. We should not leave it to the other groups.
RB: DAP does not specify what HTML-X browser shall support
... we just re-use other specification.
BS: it is important to address the related requirements
RB: W3C already takes care
BS: we should not confuse people, requirements document should specify that AppConfig is not in the scope of DAP, if it is the fact
Arve: then we should specify the same for other specs, like e.g. Geolocation. We do not do this on purpose.
BS: it should be documented what was NOT done
RB: the APIs are independent
... where should we document that?
BS: in the Scope section of the documents
... rationale should be documented
RB: should we publish a note about why something was dropped?
BS: my point is: we are silent upon some important aspects
Arve: we are not silent, other specification resolve the problems
<dom> the resolution should document clearly why we drop the item, and be put on the issue's tracker
BS: we should not stay silent
Kangchan: I agree, I propose to make a primer document that would clarify the scope of DAP.
RB: people are welcome non-normative docs/primers
... we are heading for many specs, we need editors.
... the docs should be put into CVS for further discussion
FH: what is wrong with the note in the document?
RB: we never published a req document
... if we reach consensus on concise req docs, we would result in better specs
Arve: what about an umbrella requirements document?
<darobin> ISSUE: Should we have an umbrella requirements document?
<trackbot> Created ISSUE-22 - Should we have an umbrella requirements document? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/22/edit .
<darobin> PROPOSED RESOLUTION: Drop the work item on AppConfig; discuss on list whether and where to document that as part of ISSUE-22
<darobin> RESOLUTION: Drop the work item on AppConfig; discuss on list whether and where to document that as part of ISSUE-22
no objection to the resolution
RB: no further reqs
... do we do action/issue review?
FH: no need now
Kangchan: in Korea there will be a device API related workshop tomorrow
... we will have phonegap and similar inputs
RB: feedback from the meeting will be welcome
<darobin> RRSAgent: make minutes
<darobin> fhirsch: brilliant, thanks!
<darobin> RRSAgent: stop