Audit validator list, compare w/test suite #154
Conversation
Update URLs, update draft support lists, also include validators from the JSON Schema Test Suite README file. And alphabetize PostGres, because apparently I didn't notice that when I added it.
|
@Relequestual , @adamvoss , does this look OK? |
| url: https://github.com/tatut/json-schema | ||
| draft: [3, 4] | ||
| license: MIT | ||
| - name: CoffeeScript |
There was a problem hiding this comment.
This gives me slight pause. The implementation language is CoffeeScript, but the platform/environment is JavaScript (see also .NET, implementation language in all cases is C#).
My main concern would be discoverability: it could be used by people looking for a JavaScript solution. The same would apply for TypeScript (should it ever arise).
There was a problem hiding this comment.
@adamvoss Those are good points, but this PR does not make the problem worse, so I'd rather address them separately.
There was a problem hiding this comment.
Unless you are saying that .NET is wrong and should be changed, this PR introduces the problem (in this section of the software page anyway).
There was a problem hiding this comment.
Oh I see, I was flipping .NET and C#'s roles in my head. Probably because I never think about them at all.
I would expect to find CoffeeScript as its own thing. It's hardly the first language to "compile" to another language (I am old enough to have compiled C++ with CFRONT, albeit only for compatibility tests).
Explaining to JavaScript programmers that they could use CoffeeScript (or.. ick.. TypeScript) is not our responsibility. It's more important that CoffeeScript/TypeScript users can find their own implementations.
I suppose this conflicts with how .NET is done, technically, but I assume it's done that way because the .NET/C# people thought that was better. I'm not really bothered by the inconsistency.
There was a problem hiding this comment.
The .NET libraries in question can be consumed by any .NET-platform language, the fact they are implemented in C# is irrelevant from the standpoint of the consumer. On the other hand, if there were a F# (which is a .NET language) implementation that did not put in additional effort of be compatible it would best be listed as F# because it could not be consumed by other .NET languages in a sensible way (this is similar to how the JVM-based languages are correctly listed separately here)-.
In the JavaScript/TypeScript/CoffeeScript world, the same compatibility exists. If I am writing in JavaScript/TypeScript/CoffeeScript, I am still going to go to NPM to download my dependencies where I could download jsck. It will work just fine and I might not even learn that it was written in CoffeeScript.
There was a problem hiding this comment.
This is just not a central enough concern to the JSON Schema project for me to want to hold up a PR and debate it. If you are set on blocking this, that's fine and I'll drop it, but I'm not reworking it or debating appropriate language classifications.
There was a problem hiding this comment.
@adamvoss the .NET people added their stuff under .NET, and the first CoffeeScript person added theirs under CoffeeScript (in the test suite repo, which motivated this change). I'm not inclined to contradict either of them.
There was a problem hiding this comment.
I'm not convinced this is an issue, and suggest if you feel stongly about it, open a new issue.
|
Looks good to me. We might consider adding sorting in the template, then we will know everything is always sorted. |
Update URLs, update draft support lists, also include validators
from the JSON Schema Test Suite README file.
And alphabetize PostGres, because apparently I didn't notice
that when I added it.