Powershell: Test-Json fails for valid Json.

Created on 30 Jul 2020  路  5Comments  路  Source: PowerShell/PowerShell

Steps to reproduce

OpenAPI-3.0.schema.json:
https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/schemas/v3.0/schema.json

api.json:

{
    "openapi": "3.0.0",
    "info": {
        "title": "myTitle",
        "version": "1.0"
    },
    "paths": {
        "/resource": {
            "get": {
                "responses": {
                    "200": {
                        "description": "myDescription"
                    }
                }
            }
        }
    }
}
$schema = Get-Content 'OpenAPI-3.0.schema.json' -Raw
$value = Get-Content 'api.json' -Raw
Test-Json -Json $value -Schema $schema

Expected behavior

True

Actual behavior

Test-Json: C:\Git\APIM\APIM-Service\apim-pipeline-scripts\parse-spec.ps1:3:1
Line |
   3 |  Test-Json -Json $value -Schema $schema
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot parse the JSON.

False

Environment data

```Name Value
---- -----
PSVersion 7.0.3
PSEdition Core
GitCommitId 7.0.3
OS Microsoft Windows 10.0.18363
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0鈥
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

```

Area-Cmdlets-Utility Issue-Bug

Most helpful comment

I feel confused to see support for a Microsoft product pointing to a third-party library.

This is the modern open-source world.

Not only does the PowerShell team not have any business writing a Json schema implementation, but if we did it would take (a lot of) time away from working on PowerShell itself.

Instead, people in the .NET community work hard to create and maintain libraries that we all get to reuse and can contribute back to freely. Rather than us insisting that only Microsoft can build good software, we participate in the ecosystem and in doing so de-fragment solutions to problems.

Does that mean there will be bugs? Sure, but there were bugs before too. Where once you might have filed a ticket that got internally bounced around into oblivion, this time support involves you communicating directly with the engineers who build the product, and if you don't like their response you still have the option of going to the original library to open an issue or even a PR.

So I understand your confusion, especially since PowerShell traditionally being a Windows product meant a certain form of product feedback. But now we're building PowerShell as a community out in the open, and that involves reuse, collaboration and pitching in.

All 5 comments

I can reproduce this in just NJsonSchema alone:

$json = @'
{
    "openapi": "3.0.0",
    "info": {
        "title": "myTitle",
        "version": "1.0"
    },
    "paths": {
        "/resource": {
            "get": {
                "responses": {
                    "200": {
                        "description": "myDescription"
                    }
                }
            }
        }
    }
}
'@
$schema = [NJsonSchema.JsonSchema]::FromUrlAsync('https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/schemas/v3.0/schema.json').GetAwaiter().GetResult()
$schema.Validate($json, @())

Based on that, I think this should be migrated to an issue in NJsonSchema

I created an issue in the NJsonSchema project.
https://github.com/RicoSuter/NJsonSchema/issues/1225

I thereafter found another similar issues reported one year earlier, which is still open:
https://github.com/RicoSuter/NJsonSchema/issues/1034

I feel confused to see support for a Microsoft product pointing to a third-party library. Especially since this NJsonSchema library comes installed by default with PowerShell 7.

@iSazonov has submitted PRs to convert the implementation to the newer .NET implementation (System.Text.Json), but to my knowledge the PowerShell team are currently unwilling to shift the implementation as there are some behavioural differences.

However, if this issue doesn't surface in the .NET implementation (worth investigating), perhaps that might be a reason to look at switching over once again (cc @SteveL-MSFT / @joeyaiello)

I feel confused to see support for a Microsoft product pointing to a third-party library.

This is the modern open-source world.

Not only does the PowerShell team not have any business writing a Json schema implementation, but if we did it would take (a lot of) time away from working on PowerShell itself.

Instead, people in the .NET community work hard to create and maintain libraries that we all get to reuse and can contribute back to freely. Rather than us insisting that only Microsoft can build good software, we participate in the ecosystem and in doing so de-fragment solutions to problems.

Does that mean there will be bugs? Sure, but there were bugs before too. Where once you might have filed a ticket that got internally bounced around into oblivion, this time support involves you communicating directly with the engineers who build the product, and if you don't like their response you still have the option of going to the original library to open an issue or even a PR.

So I understand your confusion, especially since PowerShell traditionally being a Windows product meant a certain form of product feedback. But now we're building PowerShell as a community out in the open, and that involves reuse, collaboration and pitching in.

.Net team actively enhance JSOM support but it seems .Net 5 has not still API for JSOM scheme validation.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

aragula12 picture aragula12  路  3Comments

JohnLBevan picture JohnLBevan  路  3Comments

andschwa picture andschwa  路  3Comments

MaximoTrinidad picture MaximoTrinidad  路  3Comments

garegin16 picture garegin16  路  3Comments