remove unit test for compatability matrix

[xiekeyang]

From
#304

and
#320 (comment)

We seems agree not to support Docker media types.
If so, this unit test for Docker media support should be removed.
And we should add constraint only for OCI types.
cc @wking

Signed-off-by: xiekeyang [email protected]

[wking]

fb63aee rolls back #145. I'm fine leaving it in to compare the
current spec against Docker JSON that has been caught in the wild.

I don't see Docker-compat as a requirement for external
implementations (it is explicitly not a requirement with #304), and I
don't think we need to facilitate Docker-compat in external
implementations (which is why I don't think we need #320). But I
don't have a problem with a spec constraint that image-spec v1
accept any Docker v2 content after a media-type change (which is what
these tests are about). On the other hand, I wouldn't mind making the
change more involved either (#224). So I don't mind either way on
this PR, but think #320 should stay closed.

[xiekeyang]

@wking
Agree. I'd close #320.
Hopefully, this PR can be accepted, because this is required by #341.
#341 resolve the descendants validation in manifest. But UT can not pass for beyond OCI cases. So this PR should be stand firstly.

[wking]

On Tue, Oct 04, 2016 at 09:33:13PM -0700, xiekeyang wrote:

Hopefully, this PR can be accepted, because this is required by
#341. #341 resolve the descendants validation in manifest. But UT
can not pass for beyond OCI cases. So this PR should be stand
firstly.

I'm not entirely sure I understand you here, but while
application/vnd.docker.distribution.manifest.v2+json is not an OCI
type, a compliant application/vnd.oci.image.manifest.list.v1+json MAY
reference one. #304 only requires OCI unpackers to understand the OCI
types, and an OCI manifest-list pointing at a Docker manifest should
get a “this may not be portable” warning from the image-validator but
should not raise a validation error. The same applies to other Docker
types. So I don't see a need to remove these compatibility tests (but
I wouldn't mind if we did).

On the other hand, #341 would error instead of printing a “may not be
portable” warning, so I agree that we don't want to handle this
portion of the validation in JSON Schema 1.