Enable JSON schema validation for import

[florelis]

Enabling validation of JSON files for import according to the schema.

• Extracted common logic from existing manifest JSON validation.
• Added new shared items project for the schema resource.
• Added validation when reading the import file. The caller already handled the error case and needed no changes.
• Enabled existing tests for this.

Microsoft Reviewers: Open in CodeFlow

[github-actions]

Misspellings found, please review:

• PACKAGESSCHEMA

To accept these changes, run the following commands from this repository on this branch

pushd $(git rev-parse --show-toplevel)
perl -e '
my @expect_files=qw('".github/actions/spelling/expect.txt"');
@ARGV=@expect_files;
my @stale=qw('"validator valijson valueiterator "');
my $re=join "|", @stale;
my $suffix=".".time();
my $previous="";
sub maybe_unlink { unlink($_[0]) if $_[0]; }
while (<>) {
  if ($ARGV ne $old_argv) { maybe_unlink($previous); $previous="$ARGV$suffix"; rename($ARGV, $previous); open(ARGV_OUT, ">$ARGV"); select(ARGV_OUT); $old_argv = $ARGV; }
  next if /^(?:$re)(?:(?:\r|\n)*$| .*)/; print;
}; maybe_unlink($previous);'
perl -e '
my $new_expect_file=".github/actions/spelling/expect.txt";
use File::Path qw(make_path);
make_path ".github/actions/spelling";
open FILE, q{<}, $new_expect_file; chomp(my @words = <FILE>); close FILE;
my @add=qw('"PACKAGESSCHEMA "');
my %items; @items{@words} = @words x (1); @items{@add} = @add x (1);
@words = sort {lc($a) cmp lc($b)} keys %items;
open FILE, q{>}, $new_expect_file; for my $word (@words) { print FILE "$word\n" if $word =~ /\w/; };
close FILE;'
popd

[JohnMcPMS]

LoadResourceAsSchemaDoc [](start = 49, length = 23)

How will we determine which schema to load in the future when there are more than one version? That can probably be a problem for future developer, but let's consider if we are just putting off the work or if we are making that work harder.

For instance, will a file with no "schema" json item validate as good? Do we want to support that and thus default to V1 schema if no value present? Or would we prefer to require the "schema" to be present and that it match the value that we expect, regardless of version.

[florelis]

In the future we could load the schema depending on the $schema property, and have some fall back if it is missing or not recognized (e.g. use latest schema).

This does not validate that the file has a $schema property or that it has a specific value. We may be able to require it in the schema if we wanted to.

If we create newer versions this function will accept them as long as they are backwards compatible. All the nodes accept additional unrecognized properties to allow room for extending without causing validation failures.

[JohnMcPMS]

I think we should require the $schema property and that it contains the expected value, even if we don't actually use it to select the schema to use yet. This seems like something that should be done by the code rather than in the schema file itself.

[JohnMcPMS]