See also: IRC log
<trackbot> Date: 05 October 2011
<fjh> Agenda: /topic http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0001.html
<fjh> s;Agenda: /topic http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0001.html;;
<scribe> Scribe: Josh_Soref
<Clarke> How do we know which number is us?
<fjh> TPAC registration reminder, deadline 10 Oct hotel, 14 Oct registration, http://www.w3.org/wiki/TPAC2011
<fjh> http://lists.w3.org/Archives/Member/member-device-apis/2011Sep/0003.html
fjh: TPAC registration deadline (fee increase) is coming shortly
<fjh> questionnaire for noting remote attendance fixed, http://lists.w3.org/Archives/Member/member-device-apis/2011Oct/0000.html
Clarke: this is my first
TPAC...
... Should i attend the TPAC Plenary?
fjh: there is an Unconference bit at the Plenary which has session related to DAP architectural approach, JS API and HTTP-based APIs
darobin: in general attending the
Plenary is useful
... even if only for the social benefits
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/att-0134/minutes-2011-09-28.html
RESOLUTION Minutes from 28 Sep are approved
fjh: there was a discussion of
Battery on the TF mailing list
... dom sent a message about it
[ Note that the TF Mailing list is not currently archiving correctly ]
AnssiK: please join the mailing list
<dom> [ indeed, Josh_Soref; I've asked for this to be fixed but haven't heard back yet]
AnssiK: otherwise we'd be forking
the discussion
... so we need to direct all discussion of Battery to that
list
fjh: please sign up if you're interested so you don't miss that discussion
darobin: if you need help signing up, please contact me
<fjh> Draft, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0136.html (Jose)
<fjh> comment, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0138.html
fjh: I know Jose and dom sent emails
Dzung_Tran: There's work to be
done esp. with Timestamp and Accuracy
... I'll check something in this week
<dom> welcome jose to DAP, jose
jcantera: We're also thinking on
the discovery of sensors available
... using this approach you could cover discovery
... [ under sensors ? ]
Claes: I'm glad that Discovery is
continuing
... have you discovered the scope of where sensors can
exist?
... sensors can be internal to the device
... or connected
... or in the local network
... or they can be in the cloud
jcantera: the idea is to have a
method
... for example listSensors
... and you can provide a type of sensor
... which would return a reference to a sensor of that
type
... if the listSensors implementation can detect a sensor in
the environment
... then you could get access to a device that isn't within the
device per se
... this approach covers the Discovery use case
... the other approach would be to have some binding between
Sensors
... and Discovery.
... That path could delay Sensors.
Claes: I can understand making
Sensors not depend on another specification
... I sent a mail to the mailing list
... where I provide information about the Webinos API and
Discover
jcantera: Leaving things
separated between Sensors and Discovery
... where Discovery returns something which could then be used
by Sensors
... [ is possible ]
... I'll send an updated proposal
Claes: another issue was needing
to expose a method for
... details about the discovered sensor
... there are use cases where a web application wants to be
tailored to a specific sensor
... this sort of information is exposed by Android
jcantera: Yes, I understand there
are interesting attributes available from the platform
... we could for example have something in the api for sensor
metadata
<Claes> http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0004.html
dom: To reiterate my suggestion
<darobin> +1
dom: we should remove the part of the Sensor api that overlaps with the DeviceOrientation spec
<AnssiK> +1 to remove overlapping parts
jcantera: Should we have the
Sensor API agnostic to the data types it provides?
... or just have it drop the conflicting bits?
dom: my suggestion is simply
dropping the overlap
... if we see value in generic data types, we can do that
... but for now, we should start with more concrete items and
avoid the overlap
darobin: we also see some value
in more lower level bits than provided by the Orientation
spec
... for that, it would be valuable to discuss that with the
GeoLocation WG
... which manages that spec
jcantera: I agree with dom, that
we should avoid confusion/conflict with other
groups/specs
... from a technical perspective, DeviceMotion is not targeted
to get Raw Sensor Data
... it's designed to get general motion
... which involves removing Noise and other stuff
<dom> (I'm fairly sure that at least Firefox sends raw data for devicemotion)
<fjh> +1 avoid overlap
<darobin> [it's worth finding out]
jcantera: You also can't control the precision, resolution, or time intervals
<dom> [this sounds like good feedback to send to the Geo WG :) ]
jcantera: Could we contact the Editors of that spec about this?
dom: I'd suggest you send
feedback to their mailing list
... I'm not sure they've fully considered them
... I agree these considerations need to be discussed
darobin: it's especially important to give them use cases for providing Raw information
jcantera: One of the use cases is
Games
... in Games, you need to have a good rate of delivery of
sensor data
... otherwise the game will not be "responsive"
Clarke: My question is about
Scope
... there seems to be a specific type of Sensor, covered
here
... things relating to Context...
... things you'd find in a mobile phone
... in other groups I'm in, we're looking at more a broad
scope
... things like Burglar alarms, Fire alarms, Temperature,
...
... If we aren't looking at that, we should make a note that
they're things which we could look at in the future
<Claes> +1 for Clarke's comment
jcantera: We have left the API
open to deal with new data types
... the spec has defined a vocabulary of sensors
... but it isn't closed to new sensors
... Concerning discovery,
... let's have an API that can work seemlessly with
Discovery
... Or have a simple mechanism to support simple
Discovery
... give me whatever Sensors are in the Environment and then I
will query them
+1 to darobin's proposal to not have useless prefixes/things that look like schemes
Clarke: I agree with focusing on
a subset of usecases
... if we're going to have a Sensor api that's general enough
to cover sensors that are included in other
specifications
... Do we want to include Actuators?
jcantera: Actuators being things where we can set values?
<fjh> are we having scope creep here?
Clarke: Right, setting values on a Thermostat, or Ringing a bell
jcantera: That wasn't initially in the scope
Clarke: I just want to be clear on the scope
<Dzung_Tran> I think we should do that later
<dom> +1 to start with a limited scope (local sensors)
<darobin> +1 indeed
<Zakim> Josh_Soref, you wanted to object
<darobin> [I think that if we have a decent model to expose sensor data for local sensors, it should be easily adapted to expose remote sensors]
<fjh> josh_soref: want interop between various sensors and applications as consumer
<fjh> josh_soref: concern about vendor name and model details
Clarke: Let's say that I want to customize my application to details from a specific sensor
<Zakim> Josh_Soref, you wanted to respond
<darobin> Josh_Soref: a long time ago a browser was called Mozilla, people started UA sniffing for it, and now all browsers are identified as Mozilla
<fjh> josh_soref: concern about analogy web browser sniffing for features, only work with specific browser etc
<darobin> Josh_Soref: providing brand, etc. information is not beneficial to anyone
<AnssiK> contrast this against feature detection (good) vs. navigator.userAgent sniffing (bad)
Clarke: if you expose the
data/attributes in a standardized way
... and you also have a textual name of your company
... is that ok?
... or should you be forbidden to expose the name of your
company?
<Dzung_Tran> I don't see a use for it
<fjh> so what you are saying is that if you don't convey company/product identity information then requiring a specific company/product for feature can be prevented
<fjh> clarke: this eliminates some branding
<fjh> josh_soref: branding at this level doesn't matter
Josh_Soref: it's true that vendor information exists at lower levels, but those should only really be relevant at most at the Device Driver layer
Clarke: I have one use case which
is legitimate for branding
... Say I have 3 printers available
... As a user, having those names available is useful to me
darobin: I agree there's a use
case for that
... I suspect that we'll be more successful
... if we let people add the brand info they want to, and
recommend that developers rely on feature detection for most
cases, which is a known best practice
... Recommend that services not rely on brand names
Clarke: I hope that textual information isn't a big concern
[ note that UserAgents are Textual Information, as was the iPod-iTunes vendor ID , and they were both heavily abused ]
Claes: I'd like to ensure that there are at least locally connected devices
<fjh> have a SHOULD NOT use brand info for feature detection??
Claes: I agree that we shouldn't duplicate other existing devices
<Zakim> darobin, you wanted to ask where the "sensor:" prefix comes from and if we can just kill it
Claes: For demo purposes,
DeviceOrientation is a good demo
... even though it shouldn't necessarily something that should
be included in the end
darobin: concerning the sensor
api
... I was wondering where the 'sensor:' prefix comes from
... and if it's really useful
<dom> +1 ; the SensorConnection() constructor already serves as namespacing for events
darobin: i think 'temperature' is better than 'sensor:temperature'
jcantera: the intention initially was to have a URI for sensors
darobin: do you think that's actually useful?
jcantera: if you could do <sensor:themometer/specific-instance>
<dom> -1 on URI for specific sensors
jcantera: you could have specific refrences that you could individually reference
darobin: wouldn't it be simpler to just pass parameters to a constructor?
<darobin> new SensorConnection("temperature", { name: foo }) vs new SensorConnection("sensor:temperature/" + foo);
jcantera: you prefer not to have a URI?
darobin: yes
jcantera: ok, I agree, that can be dropped
darobin: it's a bit dodgy to have
a URI you can't use in the URL bar
... or link to
... etc.
<Zakim> Josh_Soref, you wanted to note that the UA can let the user see this without exposing it to web apps
<darobin> +1 for start simple — add complexity when use cases come in
dom: the question of how do you
keep track of single sensors vs. multiple sensors
... requires more thinking
... and should be addressed later
darobin: should we have an issue about Single v. Multiple sensors?
<darobin> ISSUE: How to handle exposing single vs multiple sensors of the same type
<trackbot> Created ISSUE-120 - How to handle exposing single vs multiple sensors of the same type ; please complete additional details at http://www.w3.org/2009/dap/track/issues/120/edit .
<Zakim> darobin, you wanted to say blah blah
<fjh> josh_soref: about use case of picking printer, this is essential for multiple sensor use case
<fjh> ... once user picks sensor then app doesn't need branding info
<dom> +1 for UA to be a broker for selecting sensors (but that needs refinement)
<fjh> ... suggests ua exposes information selectively depending on whether discovery or not
darobin: proposals to the mailing
list would be appreciated
... someone could take an action item
<darobin> ACTION: Josh to write to the list to explain UA mediation in selecting sensors [recorded in http://www.w3.org/2011/10/05-dap-minutes.html#action01]
<trackbot> Created ACTION-456 - Write to the list to explain UA mediation in selecting sensors [on Josh Soref - due 2011-10-12].
fjh: well, this was touched on in Sensors discussion ...
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0141.html
<AnssiK> btw. thanks Claes for updating http://www.w3.org/2009/dap/wiki/ServiceDiscoveryComparison
<fjh> +1 thanks to Claes for the comparison wiki page
Claes: there will be a post to the list on Use Cases
Clarke: i think the next step is
to try to consolidate them
... our goal is to determine which use cases can't be covered
with current specs
... If we could work the Webinos use cases into that, that
would be great
Claes: We're working on
that
... and hopefully we can talk more about that next week
darobin: any volunteers to start editing a document?
Clarke: we've already created a document
link?
<Claes> http://www.w3.org/2009/dap/wiki/ServiceDiscoveryUseCases
<dom> http://www.w3.org/2009/dap/wiki/ServiceDiscoveryUseCases
Clarke: if you want to edit that wiki, please contribute, especially for consolidation
darobin: that's a good first
step
... the next step would be to try to draft something into a
spec
... but is this too early?
Clarke: the spec that Opera and
Cable Labs are submitting
... is based on the w3 requirements listed here
[ time check - we're past the 1 hour mark -- which is well over our recent average ]
darobin: if people from Webinos
are comfortable, i'd like to encourage a draft be put into
cvs/Hg
... objections?
Claes: i'd rather we wait a week, i think we need to have a bit more discussion
darobin: anything else on our agenda for Discovery?
[ no ]
<darobin> http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011,_Santa_Clara_%28TPAC%29
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0010.html
fjh: he suggested next steps for
HTML Media Capture, WebRTC and TAG
... for Joint Meetings
... I'm not sure what to do with HTML Media Capture
darobin: I don't know that a joint meeting with the HTML WG would be useful
fjh: WebRTC would be useful
darobin: TAG will be a discussion about HTTP based APIs
fjh: it's really one or two people joining us
darobin: don't hesitate to edit
the Wiki
... add topics to the Top
<fjh> TAG is having architectural item on its agenda this week
darobin: if you have preferences
for times (because of conflicts or you're calling in),
certainly tell us
... we'll try to work that in
... questions on the TPAC agenda?
<darobin> RRSAgent: stop
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Scribe Josh_Soref// Succeeded: s/could address JS API/has session related to DAP architectural approach, JS API and REST/ Succeeded: s/REST/HTTP-based APIs/ Succeeded: s/that the/that the TF/ Succeeded: s/XXX issue/discovery of sensors available/ Succeeded: s/mail to the task list/mail to the mailing list/ Succeeded: s/Zakim: mute me// Succeeded: s/contract/contrast/ Succeeded: s/XX2/let people add the brand info they want to, and recommend that developers rely on feature detection for most cases, which is a known best practice/ Succeeded: s/instant/instance/ Succeeded: s/name: foo/name: "foo"/ Succeeded: s/name: "foo"/name: foo/ Succeeded: s/sensortemperature/sensor:temperature/ Succeeded: s/covered/touched on / Succeeded: s/Sensors/Sensors discussion/ Succeeded: s/over/past the 1 hour mark -- which is well over our recent average/ Succeeded: s/seems more important/would be useful/ Succeeded: s/we have to join with MediaCapture, WebRTC and TAG/he suggested next steps for HTML Media Capture, WebRTC and TAG/ Succeeded: s/AoB/AOB/ Found Scribe: Josh_Soref Inferring ScribeNick: Josh_Soref Default Present: Josh_Soref, dom, +46.1.08.01.aabb, darobin, +1.503.380.aacc, Claes, AnssiK, fjh, wonsuk, jcantera, Sakari_Poussa, clarke, +1.503.542.aaee, Dzung? Present: Josh_Soref dom +46.1.08.01.aabb darobin +1.503.380.aacc Claes AnssiK fjh wonsuk jcantera Sakari_Poussa clarke +1.503.542.aaee Dzung? Robin_Berjon Frederick_Hirsch Dzung_Tran Dominique_Hazael-Massieux Anssi_Kostiainen Claes_Nilsson Jose_Cantera Clarke_Stevens Wonsuk_Lee Regrets: Ernesto_Jimenez Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0001.html Found Date: 05 Oct 2011 Guessing minutes URL: http://www.w3.org/2011/10/05-dap-minutes.html People with action items: josh[End of scribe.perl diagnostic output]