Update to new schema #86

teoli2003 · 2016-12-04T12:10:02Z

No description provided.

… in Firefox (mdn#109)

wbamberg · 2017-04-28T21:30:46Z

compat-data-schema.md

+following properties:
+
+#### `"version_added"`
+Contains a string with the version number the sub-feature has


This is an extra suggestion, but I think we should define and enforce, for each runtime, what the version syntax must be. I'm thinking here of something like: mdn/kumascript#131 - are Edge versions like "12.34567", or "34567" or "12"? If we don't define this, then we'll end up with a mix, and it will become really hard to work with the data.

I think it is an interesting idea: I quite like it, though it may may be complex to define and maintain. I think we should do, or at least study, this in a follow-up. Could you open an issue so that this is tracked?

You'd also need to have uniform data to begin with. When I started contributing to MDN, all the reference to Chrome version numbers were 3 digits ("39.0"). Chrome doesn't do it that way and as far as I can tell never did. I've been trying to correct to 2 digits ("39") wherever I can, but right now it's a mix.

wbamberg · 2017-04-28T21:40:06Z

compat-data-schema.md

+      …
+    }
+
+We are using semantic versioning, so the version is a `string` containing three


Should link to http://semver.org/ - actually, IMO, we should link instead of including the three bullets below. Either we are semver, in which case the definitions must be the same, and by duplicating it we just allow for incompatibility to creep in. Or we are not, in which case we shouldn't say we are.

Good point.

wbamberg · 2017-04-28T21:53:31Z

compat-data.schema.json

      },
-      "required": ["Chrome", "Opera", "Edge", "Firefox", "Firefox for Android"],
-      "additionalProperties": false
+      "additionalProperties": true


Why true?
(I feel like being restrictive now makes it easier for us to be less restrictive in future without breaking compat.)

Also, I wonder if we could usefully add "additionalProperties": false to some of the other definitions.

This came from a comment from @stephaniehobson on dev-mdc. If some browser (like Firefox OS) become deprecated, we can just ignore it, without having to fix the schema (and all the data)

Practically I know that other browser vendors (especially on mobile) are interested to contribute, so having an open list, allow them to come and make the PR.

For more "additionalProperties": false. Seems like a good idea.

So, I've kept the "additionalProperties": true there.

I've added several "additionalProperties": false to the schema, and that's was a really good thing: I found 4 (trivial) errors in the compat data we had, and fixed them.

wbamberg · 2017-04-28T22:03:35Z

compat-data.schema.json

      "type": "object",
      "properties": {
-        "Basic support": { "$ref": "#/definitions/feature" }
+        "support": { "$ref": "#/definitions/subfeature" }


should this be "basic_support"?

Yes, I initially thought this was a merge error of my side, and it should be "basic_support". This line (98) is in fact redundant (the "required" and "additional_properties" deal with it), but it makes more clear to call explicitly "basic_support"

wbamberg · 2017-04-28T22:08:13Z

compat-data.schema.json

+      ]
+    },
+
+


extra blank line

wbamberg

I think the stuff in the docs about "support" versus "basic" versus "basic_support" should be cleared up.

I'd like to understand better the reasoning behind "additionalProperties": true, and it looks to me like the schema has "support" when it should be "basic_support".

I'd like us to consider defining and enforcing version syntax for different browsers, because I think not doing this will give us headaches in the future. But that's more of a feature request than a bug.

But I think in general, it looks really good! 👍

wbamberg · 2017-05-02T04:43:33Z

compat-data-schema.md

+the version of schema used inside the file.
+
+    {
+      "version": "1.0.0",


It seems like "version" could easily be the name of an identifier. For example manifest.json has a version key that will appear as an identifier in the data (not at the top-level, but we could imagine this happening).

Should we call it __compat_version? Alternatively we could shift the data down a level, and have the top-level look like:

{ "version": "1.2.3", "data": {...} }

That seems less hacky, but introduces another level of nesting, and we already have a lot of that.

This is a good point. I don't like "__*" even if we are using it once, so I like the "data" idea. It also allows to extend this in the feature (if needed). I will apply this.

…perties)

… about "data"

teoli2003 · 2017-05-02T13:10:17Z

So I have fixed all comments but:

The extra suggestion (browser version numbers), that I think should be a separate issue.
The "additional_properties": true for more browsers (or other tools).

I think in both cases, not limiting it now will allow us to see if it is a problem, or if new browsers are coming often, or if we let too many errors through because of not having things enforced at the schema level, …

What do you think, @wbamberg ?

wbamberg · 2017-05-02T16:22:12Z

So I have fixed all comments but:

The extra suggestion (browser version numbers), that I think should be a separate issue.

On this, actually, I'm torn. On the one hand, I agree that it will be complicated and potentially time-consuming to define version number schemas for the different browsers. And I really don't want to block this PR any longer (and neither do you I guess).

On the other hand, if this is a thing we might want to do, it would be a breaking change and might invalidate existing data. So is it unwise to not examine it before landing, just so we meet an essentially artificial deadline?

The "additional_properties": true for more browsers (or other tools).

This I'd like to argue with a bit more. It's easy to add new browsers, if we want to. On the other hand, "additional_properties": false protects us from typos like "friefox" and "chome". We don't have any other tests for the compat data, so it seems good to me to make it strict.

I think in both cases, not limiting it now will allow us to see if it is a problem, or if new browsers are coming often, or if we let too many errors through because of not having things enforced at the schema level, …

I think this is backwards. It's easy to change the schema to be more forgiving. It's hard to change it to be stricter.

Elchi3 · 2017-05-03T19:17:48Z

I filed issue #168 for the version validation. I will think more about whether or not this is blocking us.

I agree that additional_properties should be false as we need to prevent typos. More environments/browsers can be added easily in the schema and this will each time drive a discussion on how to name a vendor correctly and canonically.

This is amazing work and a massive PR. I would like to split it in several parts though (and make nicer commits [not 250+]):

PR that has the schema and the readme
PR that has CSS data
PR that changes HTTP data
PR that changes js/webgl data

We can control with travis.yml when we want to validate what for the CI test not to fail and for 3 and 4 we are blocked on updating kumascript, so that can't be done now but only soon. Will's WebExtension data is already ready to be merged, so we will need 1 for it.

jpmedley

Also, are you validating the format of version numbers? I couldn't find it if you are. Chrome needs to be two digits. When I first started contributing to MDN I noticed that they tended to be three digits, "39.0" for example. All of Google's own web pages would just use "39". I've been changing them for about a year now.

jpmedley · 2017-05-03T20:41:11Z

compat-data-schema.md

+alternate names, as well as notes.
+
+The currently accepted browser identifiers are:
+* `"webview_android"`, Webview, the former stock browser on Android,


Actually, it's the browser bundled with Android for use in native and hybrid apps. Since Android 4.4 (KitKat) it has been based on the Chromium open source project, the same project on which Chrome is built.

Hey @jpmedley. I suggested that we should validate version numbers, here: #86 (review), and Florian just filed an issue for it: #168. I'm sure it would be great to get your input into what the format should be for Chrome.

stephaniehobson · 2017-05-03T21:08:47Z

If we make "additional_properties": false can we add new browsers without adding a new version? I would hate to have to increase the version every time we add a new browser.

stephaniehobson · 2017-05-03T21:09:19Z

... without adding a new version to the data API. Sorry, that was unclear.

teoli2003 · 2017-05-04T07:55:01Z

@stephaniehobson "additional_properties": false means we have to change the minor version of the version number each time we add a browser. E.g. "3.0.0" -> "3.1.0". (Files with the schema 3.0.0 are still valid in 3.1.0, but not the opposite.

So here are the arguments:

false means we have to update the schema (and therefore have a PR and a discussion)
false means a minor version update of the schema (old files are still compatibles, but not new ones with the old schema)
false will allow us to automatically detect typos in browser names

Side point:

if we go to have clearly defined version numbers for each browsers, we will need to update the schema anyway for each new one (unless we default to a simple string)

teoli2003 · 2017-05-04T15:13:31Z

I'm closing this in favor of the 4 PR, requested by @Elchi3:

PR #170: new schema
PR #171: CSS
PR #172: HTTP
PR #174: JavaScript

Once PR #170 lands, a rebase of PR #171, #172 and #174 will be needed but should be trivial.

teoli2003 force-pushed the schema-with-identifier branch 10 times, most recently from 7254d06 to cfa25ef Compare December 6, 2016 07:29

teoli2003 force-pushed the schema-with-identifier branch 5 times, most recently from 5abc5c8 to dab651c Compare March 15, 2017 10:34

teoli2003 force-pushed the schema-with-identifier branch 2 times, most recently from 0f9f005 to f9bfbe8 Compare April 9, 2017 11:17

wbamberg and others added 13 commits April 26, 2017 15:47

Fix sessions.Filter version (mdn#101)

3b8fdb5

Bug 1308057 - Merge WebGLTimerQuery into WebGLQuery

f860087

Bug 1308057 - EXT_disjoint_timer_query is no longer Draft

e38302a

Added topSites data (mdn#102)

c1d84ef

Document Tab.cookieStoreId (mdn#103)

5d12bfb

WebGL2 is supported in Chrome 56 and Opera 43 (mdn#104)

c42ad5d

Fix requestBody note for Firefox (mdn#105)

685978e

Note cookieStoreId in tabs.query and tabs.create (mdn#106)

cc1d810

Note that Session objects don't contain Tab.url in Firefox (mdn#108)

b29712f

Note that sessions Tab objects also don't contain title or favIconUrl…

01db98b

… in Firefox (mdn#109)

IE 8 supports ALLOW-FROM

1317abb

Latest opera doesn't support allow_from

ef8d62e

XTO was implemented in Firefox 50 (bug 471020)

4ccd3af

wbamberg reviewed Apr 28, 2017

View reviewed changes

wbamberg requested changes Apr 29, 2017

View reviewed changes

wbamberg reviewed May 2, 2017

View reviewed changes

teoli2003 added 9 commits May 2, 2017 10:52

Fix comment from PR

2319685

Make the schema a bit more strict (data, version but no additionalPro…

4c8ebe9

…perties)

Typo in schema

a73e7a3

Update to schema with "data"

084ba1c

Update to schema with "data"

664e56d

Update to schema with "data"

f23c5eb

Update to schema with "data"

1730321

Removed extra blank line

68f3d3c

Update schema description to link to semver docs, as well to add info…

9862548

… about "data"

jpmedley requested changes May 3, 2017

View reviewed changes

teoli2003 mentioned this pull request May 4, 2017

Addition of a new schema #170

Merged

Elchi3 mentioned this pull request May 4, 2017

[Schema] Disallow additionalProperties in compat_block statement #173

Closed

teoli2003 closed this May 4, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update to new schema #86

Update to new schema #86

teoli2003 commented Dec 4, 2016

wbamberg Apr 28, 2017

teoli2003 May 2, 2017 •

edited

jpmedley May 3, 2017

wbamberg Apr 28, 2017

teoli2003 May 2, 2017

teoli2003 May 2, 2017

wbamberg Apr 28, 2017 •

edited

teoli2003 May 2, 2017

teoli2003 May 2, 2017

wbamberg Apr 28, 2017 •

edited

teoli2003 May 2, 2017 •

edited

wbamberg Apr 28, 2017

teoli2003 May 2, 2017

wbamberg left a comment •

edited

wbamberg May 2, 2017

teoli2003 May 2, 2017

teoli2003 May 2, 2017

teoli2003 commented May 2, 2017

wbamberg commented May 2, 2017 •

edited

Elchi3 commented May 3, 2017

jpmedley left a comment

jpmedley May 3, 2017

wbamberg May 3, 2017 •

edited

stephaniehobson commented May 3, 2017

stephaniehobson commented May 3, 2017

teoli2003 commented May 4, 2017

teoli2003 commented May 4, 2017

Update to new schema #86

Update to new schema #86

Conversation

teoli2003 commented Dec 4, 2016

Choose a reason for hiding this comment

teoli2003 May 2, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wbamberg Apr 28, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wbamberg Apr 28, 2017 • edited

Choose a reason for hiding this comment

teoli2003 May 2, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wbamberg left a comment • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

teoli2003 commented May 2, 2017

wbamberg commented May 2, 2017 • edited

Elchi3 commented May 3, 2017

jpmedley left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wbamberg May 3, 2017 • edited

Choose a reason for hiding this comment

stephaniehobson commented May 3, 2017

stephaniehobson commented May 3, 2017

teoli2003 commented May 4, 2017

teoli2003 commented May 4, 2017

teoli2003 May 2, 2017 •

edited

wbamberg Apr 28, 2017 •

edited

wbamberg Apr 28, 2017 •

edited

teoli2003 May 2, 2017 •

edited

wbamberg left a comment •

edited

wbamberg commented May 2, 2017 •

edited

wbamberg May 3, 2017 •

edited