[IndexedDB] Spec Status Update

[Joshua Bell]

A quick pre-TPAC update on the status of Indexed DB for the Web Platform WG:

The "first edition" of Indexed DB[1] became a W3C Recommendation in January
2015. Since then, the editors (Joshua Bell from Google and Ali Alabbas from
Microsoft) have started work on a "second edition" [2] Editor's Draft. The
work so far has been incremental and following the "edit then review" model
favored by the working group. To summarize the work so far:

* Spec moved to GitHub [3]
* Feature request wiki migrated to GitHub issue tracker [4]
* Moved to ReSpec "contiguous IDL" and various respec fixes
* Spec overhauled to describe methods in imperative/procedural form
* ECMAScript binding cases for keys and keypaths not covered by Web IDL
specified explicitly
* Several new attributes, methods and events already shipping in Gecko
and/or Blink have been documented:
  * event on IDBDatabase for abnormal close
  * getAll and getAllKeys methods on IDBObjectStore and IDBIndex
  * objectStoreNames attribute on IDBTransaction
  * openKeyCursor on IDBObjectStore
  * test cases for these have been submitted to web-platform-tests
* In addition, some more aspirational changes that have not shipped yet in
any implementations have been specified based on feature requests,
including binary keys, renaming stores/indexes and a handful of other
methods.
* There is current discussion (mailing list, github, ...) for some some of
the most popular but also more substantial requests, including a
Promise-friendly extension to the API and an observer API

Feedback is appreciated and welcome, especially in these areas:
* Overall review to ensure that the "imperative" rework of the spec did not
introduce behavior changes
* Intentional behavior additions to the spec (called out as "☘ new in this
edition ☘")
* Review of the tracked issues [4] - comments, clarifications, indications
of support or disagreement, or just plain bikeshedding
* In particular, comments on the Promises proposal[5] would be helpful, as
we're trying to introduce minimal changes to avoid forking the API

[1] First Edition TR: http://www.w3.org/TR/IndexedDB/
[2] Second Edition ED: https://w3c.github.io/IndexedDB/
[3] GitHub repo: https://github.com/w3c/IndexedDB/
[4] Issue tracker: https://github.com/w3c/IndexedDB/issues/
[5] Promises proposal: https://github.com/inexorabletash/indexeddb-promises

Re: PSA: Change the Latest Editor's Drafts of WebStorage, WebWorkers, WebMessaging, Server-Sent Events and WebSockets

[Xiaoqian Wu]

> On 21 Oct, 2015, at 1:52 am, Arthur Barstow  wrote:
> 
> On 10/19/15 1:52 PM, Xiaoqian Wu wrote:
>> The Web Platform WG intents to update the Latest Editor's Drafts of a set of 
>> HTML5 API specs, including WebStorage, WebWorkers, WebMessaging, Server-Sent 
>> Events and WebSockets. As no one in WPWG has committed to work on these 
>> specs, the latest EDs will be the WHATWG version.
> 
> Hi Xiaoqian,
> 
> Is the plan to gut the current ED of all content except a link to the WHATWG 
> LS plus a message like "For the latest version of this specification use the 
> WHATWG's Living Standard.”?

Hi Art,

+1. Thanks for the good advice. 

—
xiaoqian

> 
> -Thanks, AB
> 
> 

Re: PSA: Change the Latest Editor's Drafts of WebStorage, WebWorkers, WebMessaging, Server-Sent Events and WebSockets

[Arthur Barstow]

On 10/19/15 1:52 PM, Xiaoqian Wu wrote:
The Web Platform WG intents to update the Latest Editor's Drafts of a 
set of HTML5 API specs, including WebStorage, WebWorkers, 
WebMessaging, Server-Sent Events and WebSockets. As no one in WPWG has 
committed to work on these specs, the latest EDs will be the WHATWG 
version.


Hi Xiaoqian,

Is the plan to gut the current ED of all content except a link to the 
WHATWG LS plus a message like "For the latest version of this 
specification use the WHATWG's Living Standard."?


-Thanks, AB

CfC: publish Proposed Recommendation of Web Storage 2nd Edition; deadline October 27

[Xiaoqian Wu]

This is a Call for Consensus to publish a Proposed Recommendation of Web 
Storage (Second Edition) using the [PR] as the basis. Agreement with this CfC 
means you consider the test results shows interoperability and the changes 
since CR are not substantive.

The test results for Web Storage (Second Edition) [All] indicate significant 
interoperability, with only three tests that have less than two passes [<2]. 
These three tests, including a short analysis of the failure, are:

1. ; this test failure 
(which passes on Firefox) can be considered more of a Web IDL implementation 
issue. The group believes it will get better over time as WebIDL compliance 
progresses.

2.  (which pass 
on Chrome);  (which 
pass on Chrome); The expected test results for these two test cases are not 
defined in the spec. The failures can be ignored as the spec move to PR.

We intend to remove those two [OPEN ISSUES] in the previous CR, which were 
raised in 2009, for the lack of interest from the editors and the implementors 
to continue the discussion. The current two [GIT ISSUES] are either resolved 
(#4) or non-substantive (#5).

Other changes includes:
* Fixed typos raised by issue#5 in [GIT ISSUES].
* Changed the Editor’s Draft to the WHATWG version.
* IDL update of the storage interface: setter creator void setItem(DOMString 
key, DOMString value) -> setter void setItem(DOMString key, DOMString value).
* Updated the refs to DOM and WebIDL.

We consider the changes since the CR as non-substantive. See [Diff] for all of 
changes between the CR and the draft PR.

We propose to publish the PR of Web Storage 2nd Edition under the Web 
Application Working Group, which has been merged to the Web Platform Working 
Group lately. Due to patent policy reasons, the next step for the Web Storage 
2nd Edition spec in Web Platform Working Group would be to publish a FPCR (i.e. 
a CR which is also a FPWD). Given that the Web Applications working group isn't 
closed, we believe a PR under the WebApps WG will be the simplest feasible 
option for WebStorage 2nd Edition.

If you have any comments or concerns about this CfC, please reply to this 
e-mail by October 27 at the latest. Positive response is preferred and 
encouraged, and silence will be considered as agreement with the proposal. If 
there are no non-resolvable objections to this proposal, the motion will carry 
and we will request the PR be published on November 05 2015.

Thanks.

--
xiaoqian

[PR] https://w3c.github.io/webstorage/PR-webstorage-20151105.html
[All] https://w3c.github.io/test-results/webstorage/all
[<2] https://w3c.github.io/test-results/webstorage/less-than-2
[OPEN ISSUES] http://www.w3.org/TR/2015/CR-webstorage-20150609/#issues
[GIT ISSUES] https://github.com/w3c/webstorage/issues
[Diff] 
http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2015%2FCR-webstorage-20150609%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fwebstorage%2FPR-webstorage-20151105.html

RE: App-to-App interaction APIs - one more time, with feeling

[Daniel Buchner]

I'm trying to understand exactly why you see your example ("there was a person 
who invented a "math" protocol handler. For him it meant that formulæ be read 
out loud (because his mission is making the web accessible to people with 
disabilities including eyes) but clearly there was no way to bring a different 
target.") as something this initiative is blocked by or cannot serve.

If you were to create a custom, community-led protocol definition for math 
equation handling, like web+math, apps would send a standard payload of 
semantic data, as defined here: http://schema.org/Code, and it would be handled 
by whatever app the user had installed to handle it. Given the handler at the 
other end is sending back data that would be displayed in the page, there's no 
reason JAWS or any other accessibility app would be blocked from reading its 
output - on either side of the connection.

I can't really make sense of this part of your email, can you clarify? --> 
"Somehow, I can't really be convinced by such a post except asking the user 
what is the sense of a given flavour or even protocol handler which, as we 
know, is kind of error-prone. Agree?" Asking the user what sense of a given 
protocol? Are you saying we can't ask users what apps they want to have handle 
various actions? If so, we do this all the time, in every OS on the planet, and 
I wouldn't say that simple process is error prone. Maybe I am misunderstanding 
you?

- Daniel

From: Paul Libbrecht [mailto:p...@hoplahup.net]
Sent: Sunday, October 18, 2015 9:38 AM
To: Daniel Buchner 
Cc: public-webapps@w3.org
Subject: Re: App-to-App interaction APIs - one more time, with feeling

Daniel,

as far as I can read the post, copy-and-paste-interoperability would be a 
"sub-task" of this.
It's not a very small task though.
In my world, E.g., there was a person who inventend a "math" protocol handler. 
For him it meant that formulæ be read out loud (because his mission is making 
the web accessible to people with disabilities including eyes) but clearly 
there was no way to bring a different target.

Somehow, I can't really be convinced by such a post except asking the user what 
is the sense of a given flavour or even protocol handler which, as we know, is 
kind of error-prone. Agree?

paul

PS: I'm still struggling for the geo URL scheme to be properly handled but it 
works for me in a very very tiny spectrum of apps (GMaps > 
Hand-edited-HTML-in-Mails-through-Postbox > Blackberry Hub > Osmand). This is 
certainly a good example of difficult sequence of choices.


Daniel Buchner
14 octobre 2015 18:33
Hey WebAppers,

Just ran into this dragon for the 1,326th time, so thought I would do a 
write-up to rekindle discussion on this important area of developer need the 
platform currently fails to address: 
http://www.backalleycoder.com/2015/10/13/app-to-app-interaction-apis/.
 We have existing APIs/specs that get relatively close, and my first instinct 
would be to leverage those and extend their capabilities to cover the broader 
family of use-cases highlighted in the post.

I welcome your ideas, feedback, and commentary,

- Daniel

Re: [Spec Reviews] Internationalization Best Practices for Spec Developers

[ishida]

hi Art,

On 20/10/2015 11:44, Arthur Barstow wrote:

I presume this document (or a document like this) would be used (useful)
when a spec is getting "wide review" from an internationalization
perspective.


i'm hoping it will eventually be useful even before then, since people 
working on a spec can run through the checklist to identify topics that 
need consideration. One of the aims in creating this was to get some of 
the knowledge in our i18n WG heads out there so that groups could 
self-educate.


that said, the do's and don'ts are still at an early stage of 
development, so there may be a need for discussions between groups 
before things are settled, and we intend to add more material as we go 
forward too.


if anyone reading this uses the checklist and related information, we'd 
be grateful to hear from them where there are issues and how we could 
improve things.


cheers,
ri

[Spec Reviews] Internationalization Best Practices for Spec Developers

[Arthur Barstow]

The I18N WG group published a FPWD of "Internationalization Best 
Practices for Spec Developers". This document includes recommendations 
and best practices for spec writers regarding topics such as characters, 
language, text direction, etc.


I presume this document (or a document like this) would be used (useful) 
when a spec is getting "wide review" from an internationalization 
perspective.


[[
<http://www.w3.org/TR/2015/WD-international-specs-20151020/>

*Abstract*

This document provides a checklist of internationalization-related 
considerations when developing a specification. Most checklist items 
point to detailed supporting information in other documents. Where such 
information does not yet exist, it can be given a temporary home in this 
document. The dynamic page Internationalization Techniques: Developing 
specifications 
<http://www.w3.org/International/techniques/developing-specs-dynamic> is 
automatically generated from this document. *The current version is 
still a very early draft, and it is expected that the information will 
change regularly as new content is added and existing content is 
modified in the light of experience and discussion.


Introduction

*Developers of specifications need advice to ensure that what they 
produce will work for communities around the globe.


The Internationalization (i18n) WG tries to assist working groups by 
reviewing specifications and engaging in discussion. Often, however, 
such interventions come later in the process than would be ideal, or 
mean that the i18n WG has to repeat the same information for each 
working group it interacts with.


It would be better if specification developers could access a checklist 
of best practices, which points to explanations, examples and rationales 
where developers need it. Developers would then be able to build this 
knowledge into their work from the earliest stages, and could thereby 
reduce rework needed when the i18n WG reviews their specification.


This document contains the beginnings of a checklist, and points to 
locations where you can find explanations, examples and rationales for 
recommendations made.  If there is no such other place, that extra 
information will be added to this document. It is still early days for 
this document, and it may also be used to develop ideas and organize them.


You may prefer to use Internationalization Techniques: Developing 
specifications 
<http://www.w3.org/International/techniques/developing-specs-dynamic> 
most of the time, since it uses JavasScript to help you more quickly see 
what's available and drill down to the information you need. (Where 
needed, it links to this or other documents.) There is also a 
non-dynamic version 
<http://www.w3.org/International/techniques/developing-specs> of the 
document available.

]]

If you have any comments or feedbck about this doc, please use 
<https://github.com/w3c/bp-i18n-specdev/issues>.


--