– DRAFT –
DAS Working Group teleconference

Welcome, scribe selection, agenda review, announcements

anssik: We met in Jan. Made lots of progress since then.
… Will talk about publication plan and new charter today.

Sensor APIs wide review response

https://‌github.com/‌w3c/‌sensors/‌issues/‌299

<anssik> https://‌github.com/‌w3c/‌sensors/‌issues/‌299#issuecomment-369924348

anssik: In the TAG issue (https://‌github.com/‌w3ctag/‌design-reviews/‌issues/‌207), we got a lot of feedback
… also got feedback from Security IG and PING

<anssik> Search "Proposed changes:"

anssik: Search "Proposed changes:" in this issue to find PRs corresponding to the feedbacks

<anssik> Summary: Based on the group's assessment, TAG review feedback did not yield normative changes to the specifications under wide review. The review comments helped improve various informative aspects of the specifications and readability was further improved. The review comments further reinforced group's view that the specifications are ready to advance to Candidate Recommendation stage in the near future.

anssik: the sensors specs are ready to go to CR

Sensor APIs issue review

<anssik> https://‌github.com/‌w3c/‌sensors/‌projects/‌4

anssik: I would like to congratulate the group to close all Level 1 issues of Generic Sensor

<anssik> Throw exception when screen coordinate system is not supported

<anssik> https://‌github.com/‌w3c/‌accelerometer/‌issues/‌35

anssik: propose to discuss open issues of concrete sensors specs today

anssik: I personally think feature detection of this is useful
… WDYT?

<anssik> OrientationSensor interface to provide Euler angles

<anssik> https://‌github.com/‌w3c/‌orientation-sensor/‌issues/‌43

[silence]

anssik: ok, we will make it in L1

alexander_shalomov: manual conversion in JS is needed currently
… if you search "how to use motion sensors on the web", the results use old APIs

anssik: we need to decide if this feature is in scope [in L1]

anssik: should we defer this to L2, or in a new CR of L1?

<anssik> GeomagneticOrientationSensor interface

alexander_shalomov: L2, I think.

<anssik> https://‌github.com/‌w3c/‌orientation-sensor/‌issues/‌15

anssik: ok then.

<anssik> Improve guidance on UI for user consenting

anssik: we'll defer orientation-sensor#15 to L2 too

<anssik> https://‌github.com/‌w3c/‌sensors/‌issues/‌352

anssik: this is a very recent issue
… it's about guidance on UI for user consenting
… what the spec does now is providing extension points

<anssik> https://‌github.com/‌w3c/‌sensors/‌pull/‌353

<anssik> https://‌w3c.github.io/‌sensors/#security-and-privacy

anssik: this PR basically adds a note
… in my opinion the issue is addressed
… any comment?

Mikhail_Pozdnyakov: in my opinion, this is beyond our scope
… the mitigation strategies already mitigate the potential risks

anssik: this spec is a huge improvement over the previous APIs in terms of security and privacy
… propose to close this issue; feel free to comment/reopen if you have further comments.

Sensor APIs CR readiness

<anssik> https://‌github.com/‌w3c/‌sensors/‌issues/‌355

anssik: I created a meta issue

<anssik> Generic Sensor API - https://‌w3c.github.io/‌sensors/

<anssik> Ambient Light Sensor - https://‌w3c.github.io/‌ambient-light/

<anssik> Accelerometer - https://‌w3c.github.io/‌accelerometer/

<anssik> Gyroscope - https://‌w3c.github.io/‌gyroscope/

<anssik> Magnetometer - https://‌w3c.github.io/‌magnetometer/

<anssik> Orientation Sensor - https://‌w3c.github.io/‌orientation-sensor/

anssik: the CR scope is clear
… I went through the CR requirements in the Process
… we have requested and received wide review

<anssik> must show that the specification has met all Working Group requirements, or explain why the requirements have changed or been deferred,

<anssik> https://‌w3c.github.io/‌sensors/‌usecases

<anssik> https://‌w3c.github.io/‌motion-sensors/

anssik: based on my assessment, the specs meet the requirements set forth in the DAS WG Charter
… and satisfy Sensor Use Cases as demonstrated in Motion Sensors Explainer

<anssik> must document changes to dependencies during the development of the specification,

<anssik> must document how adequate implementation experience will be demonstrated,

anssik: see changes to dependencies in the issue
… we have test suites and preliminary implementation reports

<anssik> Propose: The CR exit criterion is two interoperable deployed implementations of each feature.

<anssik> must specify the deadline for comments, which must be at least four weeks after publication, and should be longer for complex documents,

anssik: CR exit criteria means "when are we ready to move to the next stage (PR)?"

<anssik> Proposal: This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than [six weeks after its publication].

<anssik> must show that the specification has received wide review,

<anssik> Wide review received, see tracker https://‌github.com/‌w3c/‌sensors/‌issues/‌299

anssik: we will use six weeks for the deadline for comments, because there're multiple specs

<anssik> may identify features in the document as "at risk". These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.

<anssik> Proposal: No features are marked as 'at-risk'.

anssik: "at risk" means if you're not confident whether a feature will be in the final recommendation, you can mark it "at risk" and remove it before PR
… I don't identify such features in the sensors specs
… I'll send a Call for Consensus for the CR

Mikhail_Pozdnyakov: for Chrome implementation we don't need throw exception [when screen coordinate system is not supported]

Rechartering

anssik: W3C Management (hopefully) reviewed the draft charter yesterday
… do you have more info, xfq?

xfq: not currently, will check.

AOB

anssik: I'll be on vacation