Allow more primitives (boolean/number/string) about schema-dts

[Eyas]

For Booleans, to save backwards compatibility, a good shape would be:

enum BooleanEnum {
    True = "https://schema.org/True",
    False = "https://schema.org/False"
}
/** Boolean: True or False. */
export type Boolean = true | false | BooleanEnum;
export const Boolean = {
  True: BooleanEnum.True as const,
  False: BooleanEnum.False as const,
}

So you can use:

• Boolean.True,
• Boolean.False,
  as well as true and false.

[Eyas]

Thanks for the suggestions. This is helpful. For each of these, I'm basically curious if these semantics are seen as "canonical" in general. Any data / leads here will be helpful:

For Boolean types, my understanding is that these are expected to be assignable to "https://schema.org/True" and "https://schema.org/False" (from looking at Schema.org examples using Boolean). Do you have an example of true/false JSON primitives being accepted?

For width/height -- these are type Distance of QuantitativeValue. My understanding of both those types is that they're meant to encode a value with some unit attached to it. #19 as you mentioned supported using "string" for these values. I.e. "12 m" (or "13px"). Seems contrary to the intent of the schema to make distance potentially unit-less?

Ack on author/contentLocation. I know Person and Place are both accepted the Google Structured Data Testing Tool as stand-ins for {"@type": ..., "name": <string value> }. My hope was to be slightly opinionated here and allow the equivalent but more verbose version. Does this slow people down in the wild? Curious about your use cases.

[OliverJAsh]

Do you have an example of true/false JSON primitives being accepted?

See the first example here: https://schema.org/isAccessibleForFree

Seems contrary to the intent of the schema to make distance potentially unit-less?

Good point, maybe ignore my suggestion that number should be allowed!

My hope was to be slightly opinionated here and allow the equivalent but more verbose version. Does this slow people down in the wild? Curious about your use cases.

That makes sense. I'm fine with that.

Another one to consider: allow thumbnail to be a string (URL). Or would you group that with author/contentLocation, i.e. require an object?

[OliverJAsh]

My hope was to be slightly opinionated here and allow the equivalent but more verbose version. Does this slow people down in the wild? Curious about your use cases.

On second thoughts, it seems a shame if the types don't work with the examples provided on https://schema.org/, e.g. https://schema.org/ImageObject uses string for author and contentLocation.

[Eyas]

Ended up with something slightly different:

/** Boolean: True or False. */
export declare type Boolean = true | false | "https://schema.org/True" | "https://schema.org/False";
export declare const Boolean: {
    True: "https://schema.org/True" as const;
    False: "https://schema.org/False" as const;
};

This also allows users to assign the strings as-is, in addition to Boolean.True and Boolean.False.

[Eyas]

#47 will fix most of this. Note that, for

Another one to consider: allow thumbnail to be a string (URL). Or would you group that with author/contentLocation, i.e. require an object?

won't be fixed. As far as I can tell, SDTT complains if ImageObject is declared a string. Let me know if I'm wrong here.

[OliverJAsh]

@Eyas Thanks for doing that!

As for thumbnail, here's an example on the official schema website demonstrating thumbnail as a string:

https://schema.org/VideoObject

[Eyas]

Hm. Note that ImageObject doesn't always work as a string, for example:

https://lists.w3.org/Archives/Public/public-schemaorg/2019Nov/0003.html

Structured Data Testing Tool rejects when "logo" is set to a string, requiring an ImageObject set explicitly.