ShEx schemas have an RDF representation. which round-trips everything except comments and whitespaces. For example, compare 3circRefPlus1.shex to 3circRefPlus1.ttl or 1dotIMPORT1dot.shex to 1dotIMPORT1dot.ttl in https://github.com/shexSpec/shexTest/tree/master/schemas.

The RDF model asserts that a literal with a langtag is considered to have a datatype of rdf:langString. The various formats state exactly how literals with langtags are written. The former specifies how APIs behave, such as a SPARQL FILTER DATATYPE("ab"@es) = rdf:langTag; the latter specifies that it's written {"type":"literal", "value":"ab", "xml:lang":"es"}. The rules for the XML and JSON results formats are that the implicit datatype of langtagged literals is omitted.

That's way cooler than mine. @Jelabra, can that be plugged in today?

The schema for human advertises both the entities which should pass and ones that should fail. This sort of QC can help keep the schemas themselves testable and more reliable over time and many editors.

I mocked up using the ace ShExC mode in an EntitySchema.

You might not want to add it to the data itself as people persuing different use cases will want to assert that the item is linked to different schemas. When I go to test whether a schema matches <SomeSpecialWidget>, I won't be interested in whether it matches everything else it's ever been used for, so at the very least, properties linking data to schemas are advisory and not required for the validation infrastructure.

I believe that removing the results section makes it basically impossible to diagnose errors.
I added a switch ?ui=full to enable the results section and the control menu. You can see it in use in a video. Does the behavior without that switch close this issue?

propose adding E12345 to the list 'cause it's not uncommon to have to model three interconnected schemas and E123{,4{,5}} is a nice mnemonic for a scratch space for that.
other than that, +1 to calling this done.