See also: IRC log
<trackbot> Date: 05 October 2011
<scribe> Scribe: Josh_Soref
<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> questionnaire for noting remote attendance fixed, http://lists.w3.org/Archives/Member/member-device-apis/2011Oct/0000.html
fjh: TPAC registration deadline (fee increase) is coming shortly
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 ]
<dom> [ indeed, Josh_Soref; I've asked for this to be fixed but haven't heard back yet]
AnssiK: Please join the mailing list
... 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
<dom> welcome jose to DAP, jose
Dzung_Tran: There's work to be done esp. with Timestamp and Accuracy
... I'll check something in this week
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 Discovery.
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
... we should remove the part of the Sensor api that overlaps with the DeviceOrientation spec
<darobin> +1
<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
<fjh> +1 avoid overlap
<dom> (I'm fairly sure that at least Firefox sends raw data for devicemotion)
<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."
[ Josh_Soref: +1 to darobin's proposal to not have useless prefixes/things that look like schemes ]
Clarke: I agree with focusing on a subset of use cases
... 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?
Clarke: Right, setting values on a Thermostat, or Ringing a bell
<fjh> are we having scope creep here?
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
<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]
<Zakim> Josh_Soref, you wanted to object
Josh_Soref: I want interop between various sensors and applications as a consumer.
... I'm concerned about vendor name and model details being exposed to applications.
Clarke: Let's say that I want to customize my application to details from a specific sensor
<Zakim> Josh_Soref, you wanted to respond
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.
... The concern is analogous to web browser sniffing instead of simply trying to use features and only working with specific browsers, etc.
... 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
Clarke: 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
... This eliminates some branding
Josh_Soref: Branding at this level doesn't matter.
... 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
[ Josh_Soref's response to this is much later due to queuing — search for "picking a printer" ]
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 are the iPod-iTunes vendor IDs, and they were all heavily abused ]
<fjh> have a SHOULD NOT use brand info for feature detection??
Claes: I'd like to ensure that there are at least locally connected devices.
... I agree that we shouldn't duplicate other existing device APIs.
... For demo purposes, DeviceOrientation is a good demo
... even though it shouldn't necessarily something that should be included in the end
<Zakim> darobin, you wanted to ask where the "sensor:" prefix comes from and if we can just kill it
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>,
... you could have specific refrences that you could individually reference
<dom> -1 on URI for specific sensors
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.
<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> Josh_Soref, you wanted to note that the UA can let the user see this without exposing it to web apps
Josh_Soref: About use case of picking a printer, this is essential for the multiple sensor use case:
... Once the user picks a sensor, the app doesn't need branding info.
... The UA can expose information selectively (to User v. App) depending on whether discovery or not
<dom> +1 for UA to be a broker for selecting sensors (but that needs refinement)
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
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 there
[ 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%2C_Santa_Clara_%28TPAC%29
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0010.html
fjh: Wonsuk Lee 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
<fjh> TAG is having architectural item on its agenda this week
darobin: Don't hesitate to edit the Wiki,
... add topics to the top.
... 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?