tl;dr: We must formally object to the advancement of W3C Proposed
Recommendation: WebIDL Level 1
<http://www.w3.org/TR/2016/PR-WebIDL-1-20160915/>. Five (areas of)
reasons (and details) given below. -t
On Mon, Oct 10, 2016 at 11:08 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 10/11/16 1:23 AM, L. David Baron wrote:
>>
>> But given that it is worthwhile to advance snapshots of stable
>> features to Recommendation every so often, is there a reason to
>> oppose this particular snapshot, even though it's not a suitable
>> target for implementation?
>
>
> I think the main reason I'm wary of publishing a Recommendation based on
> this snapshot is that there are known things in there that are broken
Publishing a CR (much less a PR, and much much less advancing to REC)
of a spec that has known (open) normative issues ("known things in
there that are broken") is out of order and it would be correct to
formally object based on that alone. It also merits a "the chairs
should know better" process finger-wagging as it were, assuming the
"known things in there that are broken" all have issues filed.
> and
> just haven't been fixed yet due to lack of editor bandwidth.
Lack of editor bandwidth is no excuse to prematurely force a draft
through the process.
So let's take a look at the open issues in particular:
The PR links to:
https://github.com/heycam/webidl/issues
- 48 open issues
Subtracting "editoral" labeled issues:
https://github.com/heycam/webidl/issues?utf8=✓&q=is%3Aissue%20is%3Aopen%20-label%3Aeditorial
- 37 open issues
Subtracting "enhancement" labeled issues (generously assuming
"enhancement" means "for level 2+"):
https://github.com/heycam/webidl/issues?utf8=✓&q=is%3Aissue%20is%3Aopen%20-label%3Aeditorial%20-label%3Aenhancement
- 23 open issues
That alone is sufficient for a formal objection.
1. Too many open normative issues. Make it zero. (citation) For
example all of the following issues (1,2,3 link to below to-be-filed
issues) are each themselves worthy of independently blocking the PR
(even a CR).
That being said:
> For example, we know for a fact that the editor's draft will be fairly
> incompatible with this snapshot a few months from now (assuming everything
> goes as planned), necessitating changes to a number of webidl-using
> specifications to adopt some syntax changes to how mixins are declared.
> These changes are needed to get other parts of the document on a rigorous
> footing, as well as for basic clarity and sanity.
I searched those 23 open issues for "mixin" and found no open issue
with "mixin" in the title.
bz, could you file that paragraph as a gh issue, perhaps named
something like "mixin declaration syntax unstable"?
(We should then reference that issue in particular in our FO)
Continuing:
2. There is no disposition of comments. Searching for either word
reveals no links to anything showing what comments were received
during spec development and how they were resolved, including which
(if any, of explicitly stating none) of them have outstanding
commenter objections, or commenter failing to respond.
> Unfortunately, the "unstable feature" in this case is the definition of an
> "interface", which is a bit unfortunate in terms of having an actually
> usable Rec-level snapshot... :(
I found 3 open issues with "interface" in the name, and from my naive
quick read, none of them appear to be *this* issue, so this should be
filed as well, again, for specific referencing in our FO.
> There are other probably-unstable features (e.g. serializers, which no one
> implements in the specced form and no one is likely to) in the PR draft.
None of the 23 issues mention "serializer" in their names.
This should be filed (and cited), also noting that the implementation
report / test suite
https://www.w3.org/WebPlatform/WG/implementations/webidl-1/report/all.html
does not mention "serializer" either, thus this feature should have
never exited CR (never tested!)
Thus add to the list
3. Spec contains unimplemented (and untested!) features (e.g. serializer)
> I'm pretty sure this part I raised before when the snapshot idea was
> proposed.
If you can find an email permalink for that, we can (and should) cite
that as well (for 3.)
> I guess as long as we don't mind the snapshot containing stuff that we know
> we plan to remove,
We do mind, for the reasons pointed out later in the thread (wasted
time in general, incorrect technical information being referenced and
misleading implementations - causing non-interop etc.)
More:
4. There is no exit criteria mentioned in the PR or the CR. Not sure
how this was overlooked, because explicitly documented exit criteria
are supposed to be a requirement to ENTER CR, much less exit CR /
enter PR, and advance to REC!
> P.S. Yes, this is at least partly my fault for not putting nearly enough
> work into editing this spec. It puts us into a tough position where the W3C
> is demanding progress towards stabilization and that progress just hasn't
> been happening.
If W3C really wants (demands) progress, they can add more editors (or
ask the Level 1 Editors) to resolve all the above noted problems in
the Level 1 Spec.
W3C notional (external?) publication scheduling pressure is not your
burden to bear per se.
For the above "to be filed issues", if necessary at a minimum, dbaron
or I can file stub issues just for the sake of submitting this review
with links to areas the issues can be expanded, better defined,
resolved, outside of a PR response.
Continuing with that aforementioned implementation report:
https://www.w3.org/WebPlatform/WG/implementations/webidl-1/report/all.html
5. There are NUMEROUS (more than I'm going to bother copy/pasting
here) tests in the implementation report that have fewer than 2
implementations (zero or one "PASS"), thus invalidating the feature
being tested for inclusion in a PR and thus REC.
That should be enough material for a pretty solid FO.
Regarding some of the second-level effects:
On Tue, Oct 11, 2016 at 3:57 PM, Bobby Holley <bobbyhol...@gmail.com> wrote:
> On Tue, Oct 11, 2016 at 9:10 AM, L. David Baron <dba...@dbaron.org> wrote:
>
>> On Tuesday 2016-10-11 14:49 +0200, Anne van Kesteren wrote:
>> > On Tue, Oct 11, 2016 at 2:24 PM, Eric Rescorla <e...@rtfm.com> wrote:
>> > > Speaking as someone who is at best a consumer of WebIDL, what's the
>> argument
>> > > for doing a snapshot at this time?
>> >
>> > https://lists.w3.org/Archives/Public/public-webapps/2016JulSep/0004.html
>> > is presumably the argument. Those pointing out this argument is flawed
>> > have given up on that mailing list so now they get to proceed.
>>
>> The other (more important, in my opinion) piece of the argument is
>> that it's worth advancing things to Recommendation every so often so
>> that it's unambiguous that they're covered by the W3C's patent
>> policy.
>
> Yeah, from my not-super-informed perspective this is the primary benefit we
> get from W3C publication of stuff that's developed elsewhere.
>
> Most development seems to happen under the WHATWG, which hosts the specs
> that implementors look at and the umbrella under which they discuss. The
> W3C then occasionally publishes arbitrary snapshots, which don't have any
> particular technical utility but, by virtue of being published, prevent any
> of the (many) members of the W3C from claiming patent infringement at some
> later point.
Agreed, there is some utility to having W3C publish such "snapshots"
to grow the set of technology that have at least some IP coverage per
W3C Patent Policy (not going to interpret or debate specifics of that
policy here, that particular conversation is more appropriate with
legal).
That being said, it is against the W3C own policies and process to
publish RECs with features that have not properly exited CR (typically
2+ interop implementations per feature as determined by the test
suite), thus if a snapshot REC is desired, the PR must contain only
the strict "2+ interop implementations" subset of draft features.
> The only downside of this admittedly-odd model seems to be the confusion
> that results when somebody believes that the W3C publications have
> technical utility.
The only way to mitigate those effects and still have *some* IP
coverage, is for the W3C snapshots to only contain features which have
been shown to be interoperable across 2+ (preferably most if not all)
implementations tested with the spec's test suite. That's clearly not
happening here so we must object to this PR advancing to REC.
Tantek
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
