Will the result of Compile still conform? This is how I expected typebox to implement spec compatibility, since (as far as I understand) the types themselves do not encapsulate their own validation logic. Is that right?

As long as the result of Compile() is spec-compliant then I'd consider TypeBox to be a fully compatible library.

@colinhacks Hello,

Ref: sinclairzx81/typebox#1384 (comment)

As long as the result of Compile() is spec-compliant then I'd consider TypeBox to be a fully compatible library. I'd much prefer this to exposing a special StandardSchema adapter which (in my eyes) is against the goals of the spec (that is, avoiding adapters).

The Compile and StandardSchema functions are both Adapters (by this definition)

const C = Compile({ type: 'string' })            //  C: Validator<...>
//    │   │         │       
//    │   │         └────────> Json Schema
//    │   │       
//    │   └──────────────────> Adapter
//    │                    
//    └──────────────────────> Validator

const S = StandardSchema({ type: 'string' })     // S: StandardSchemaV1<...>
//    │   │              │       
//    │   │              └───> Json Schema
//    │   │       
//    │   └──────────────────> Adapter
//    │                    
//    └──────────────────────> StandardSchema 

One function is more descriptive, doesn't require a "Validator" to be considered a "Schema" and separates concerns related to runtime Result and Issue mapping (as mandated by this specification). Also Effect

... is against the goals of the spec (that is, avoiding adapters).

For the purposes of system integration, we have the same goals ... no adapters

The problem is that Standard Schema encodes Zod-like design patterns (schema / validator coupling) while presenting this design as the "Standard". This will negatively impact users of alternative software design patterns (including users of the Json Schema specification) which now need adapters to be considered "Standard" with diminished DX.

The broader concern is that Standard Schema adoption will lockout alternative software design when that doesn't need to be the case. Should Json Schema see standardization under Ecma International, developers wanting to target the specification will need adapters through Standard Schema to use it (as is the case for TB)

Adapters do provide clear explicit transformation (they are fine, fwiw)

const A = z.toJSONSchema(z.string())  // Standard Schema > Json Schema

const B = StandardSchema(A)           // Json Schema > Standard Schema      

Standard Json Schema looks like it is trying to turn this

server.post('/', {                  // 2. server compiles json schema
  body: { type: 'string' }          // 1. caller passes json schema
}, (...) => {...})

into this ...

server.post('/', {
  body: { type: 'string' }           // error: "Json Schema" is not "Standard Json Schema"
}, (...) => {...})                   //        (i.e. use Zod, Valibot, ArkType)

What should I make of this?

I am open to continued discussion, but my preference is to have TypeBox removed from the "Implementer" list as I do not provide direct support for this specification. I only provide a reference / example adapter to it (which is not published with the library)

https://github.com/sinclairzx81/typebox/tree/main/example/standard

I will take a look at the spec again next year once Json Schema has been added.

Here's the PR for the upcoming Standard JSON Schema spec: main...json-schema

"Standard JSON Schema" is orthogonal to "Standard Schema". To use your parlance, "Standard Schema" is for "validators" and Standard JSON Schema is for "schemas". In scenarios where these are unified in one construct (e.g. Zod schemas), then both specs can be implemented.

In your scenario, the intended pattern would be:

• TypeBox schemas implement Standard JSON Schema
• Compiled validators implement Standard Schema

Both specs include a standard mechanism for statically tracking inferred types.

also Effect

Effect's implementation is also against the spirit of the spec. I think it was a poor choice.

You are free to provide an adapter for JSON Schema. But I strongly recommend you also implement the spec in the result of compile. I do not understand your rationale here. It kind of sounds like you'd happily implement the spec in Compile() if it was called Standard Validator instead? If so...that's quite pedantic. A validator validates data against a known schema. It's not like these concepts are orthogonal. But feel free to make your own decisions here, I'm not going to tell you how to manage your own library.

What should I make of this?

Anyone can support regular JSON Schema schema alongside Standard JSON Schema. Standard JSON Schema provides a representation that unifies runtime type information (JSON Schema) with static type information (inferred types). The value of this is self-evident, I hope. And again, it's trivial for any tool/framework to continue accepting plain untyped JSON Schema objects and to differentiate between plan JSON Schema and Standard JSON Schema by checking for the ~standard property.