Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Addition of a new schema #170

Merged
merged 10 commits into from May 5, 2017
Merged

Addition of a new schema #170

merged 10 commits into from May 5, 2017

Conversation

teoli2003
Copy link
Member

This is the first PR resulting in the division of PR #86.

Renaming of the old schema
Adding the new schema
Adding the docs for the new schema
Dividing the travis tests so that it will be easier to merge future PR for the migration of the existing data.

@teoli2003 teoli2003 force-pushed the new-schema branch 2 times, most recently from fe9f18c to f2b8d97 Compare May 4, 2017 10:58
Copy link
Member

@Elchi3 Elchi3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I would like to land this initial schema as is now. I opened #173 to change additionalProperties to false for compat_block and there are a few other open issues, but I don't think these block the initial landing. Let's get familiar with the new schema some more by landing it and iterating on the smaller issues we identified.

@Elchi3 Elchi3 requested a review from wbamberg May 4, 2017 13:35
@Elchi3
Copy link
Member

Elchi3 commented May 4, 2017

Will, this makes travis also test the new WebExtension JSON that landed yesterday with the new schema. What do you think about merging this?

@Elchi3 Elchi3 added the schema ⚙️ Isses or pull requests regarding the JSON schema files used in this project. label May 4, 2017
Copy link
Collaborator

@wbamberg wbamberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are quite a few comments on the doc, some of which seem like errors, and some of which are just extra clarifications.

I'm wondering even whether we should have a doc at this level of detail: it's easy for it to get out of step with the schema, and the schema is really the source of truth. We could have a much shorter overview doc, and leave the details to the schema.

But I do think maybe we should have a "Checklist for reviewers" doc, that covers anything not enforced by the schema.

There are a couple of comments on the schema itself, but in general it's looking good! I'd also like to register my discomfort at including HTML and KS macro calls in notes.

@@ -0,0 +1,365 @@
# The browser-compat-data JSON format
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this doc could do with a copy-edit, but that can be done in a follow-up.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also the README should be updated to point to this document: at the moment it documents the old schema.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created issue #177 for the copy-edit part.
I updated the README file to link to the compat-data-schema.md instead of the description of the old schema.

browser-compat-data JSON format. Nevertheless there are constraints that cannot
be described inside a schema, and won't be checked by automated tests. We tried
to mark such cases in the following text with a __Not enforced by the
schema__ notice.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This notice is not actually used anywhere.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the whole note. As @wbamberg said it is not used, and as we will create a specific doc for reviewer (see issue #176), it will never be.

by making it easy to maintain by humans.

### Schema versioning
There one single information that is tied to each file, and is mandatory. It is
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are actually 2 pieces of mandatory data at the top level (version and data).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

The hierarchy of identifiers is not defined inside the schema. It is a
convention of the project using the schema.

In the MDN browser-compat case, it is:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure we should say this. It's already out of date :). We could just say "for example" instead, or omit it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid any confusion, I removed it (there is an theoretical example a few lines before)

explained in the previous paragraph, any feature has at least one sub-feature
called `'basic_support'`, but it may many more.

A sub-feature may have three properties.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's be clear which are optional and which are mandatory (as we just discussed, perhaps "support" is mandatory and the other two are optional).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

Compatibility information is stored in a `"support"` field. It may consist of the
following properties:

#### `"version_added"`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could note that this is the only mandatory property.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed


Each `string` that contains a human-readable description of the sub-feature. The
`<code>` and `<a>`, as well as the macros `{{cssxref}}`, `{{HTMLElement}}`,
`{{htmlattrxref}}`, and `{{domxref}}` can be used. See the localization section
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comments above about this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, same: KS macros should have been removed. This part is fixed.

`text-align` property is identified by `css.properties.text-align`.

The strings of an identifier are not intended to be displayed and are therefore
not translatable.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could note somewhere that identitifers can't contain dots.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that technically they can (not saying it is a good idea to do it)

"Safari Mobile": { "$ref": "#/definitions/support_statement" },
"Servo": { "$ref": "#/definitions/support_statement" },
"desc": { "type": ["string"] },
"support": { "$ref": "#/definitions/compat_block" },
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, we could make "support" mandatory.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

"additionalProperties": false
},

"feature_set": {
"compat_block": {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very much a nit, but it helps readability if you swap this and "subfeature", so I can read it all the way from the bottom up, going from a reference to its definition.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@teoli2003
Copy link
Member Author

So I made the requested changes except:

  • global copy-edit has not been done but is issue Copy-edit schema documentation #177 as suggested.
  • I didn't documented that '.' are not allowed in identifier, because I think they are (though they are not a good idea). If I'm wrong, this can be done in a follow-up too as the schema is not touched by it, only the docs.

(Note that one comment seems to be not fixed, because I fixed it by updating the text below)

@wbamberg @Elchi3 I think this is ready for a new round of review.

@wbamberg
Copy link
Collaborator

wbamberg commented May 5, 2017

Thanks for all those fixes @teoli2003 , it looks great.

global copy-edit has not been done but is issue #177 as suggested.

Sounds good.

I didn't documented that '.' are not allowed in identifier, because I think
they are (though they are not a good idea). If I'm wrong, this can be done
in a follow-up too as the schema is not touched by it, only the docs.

You are right. We talked about this a couple of days ago and I see @Elchi3 filed an issue for it: #167. I saw some regexps in the schema and thought this had made its way into the schema already, but I was mistaken :).

@wbamberg wbamberg merged commit 4cb0f23 into mdn:master May 5, 2017
@Elchi3 Elchi3 moved this from In Progress / Review Needed to Done in Migration of compat data from MDN pages May 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
schema ⚙️ Isses or pull requests regarding the JSON schema files used in this project.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants