[js refactor] mark invalid/valid

[mapsam]

We should mark fixtures as valid or invalid (or possibly some sort of enum for semi-invalids #10) so downstream applications can assert based on success/lack thereof of parsing particular fixtures.

cc @springmeyer

[springmeyer]

👍 on going with a Boolean right now of is_valid.

[joto]

There are several different (maybe overlapping) "categories" I see here:

• is valid/invalid in version 1
• is valid/invalid in version 2
• recoverable error: is invalid but reader should keep going (to next feature/next layer), for instance invalid geometry
• fatal error: is invalid and reader should stop reading from this tile (or even from the source), for instance when somebody clearly is trying to provoke a buffer overrun
• some way of saying where the problem (if any) is: in the geometry, in the tags, or more general

There are probably more.

[mapsam]

@joto since we'll likely be using these fixtures outside of a javascript library, how would you prefer to know which fixtures are valid/invalid/semi? Trying to figure out how writing tests around these fixtures can be most helpful.

For example, would you prefer some sort of directory structure like:

fixtures/
  > valid/
  > invalid/
  > semi-invalid/
  > etc/ 

Or would you be happy just parsing the information from the info.json file?

[joto]

I am happy with parsing this from a JSON file or I'll just take the info from there and hardcode it in some script or so.

Directory structure is unlikely to be enough because that can only encode one "category" (or would become overly complex with nested dirs or so).

[springmeyer]

👍 on putting in the JSON file. This would also make it easier to update when we add "categories", and less noisy git diffs.

[mapsam]

Excellent @joto @springmeyer - easier for me 😉

[mapsam]

How about this description added to the README?

---

Validity: each fixture includes information about whether they are valid according to the specification versions and possible error outcomes if they are invalid. If any of the fixtures are invalid, they must include an error field describing how to recover (or not) from the error. These can be found in the validity field of the fixture and info.json files. The following checks:

• v1 (Boolean): is this fixture valid according to Version 1.x of the Mapbox Vector Tile spec
• v2 (Boolean): is this fixture valid according to Version 2.x of the Mapbox Vector Tile spec
• error (String): describes if the encoder/decoder should recover from this error or stop completely. Values are
  • recoverable: should the encoder/decoder continue move on and continue its work? For instance, if invalid geometry is found, can the encoder safely move to the next feature?
  • fatal: the encoder should completely stop its process
  • ... more

[joto]

@mapsam Looks good to me. We'll see how well it works once we are testing our tests and can always introduce more categories or so.

[mapsam]

👍 indeed - thanks for 👀 @joto!

[mapsam]

First pass completed in 9daefde

[springmeyer]

👍