>Instead of requiring verbose low-level parameters such as scales, axes, spacing, and layout.

Ok, Microsoft is conflating two different things here: LLMs don't really care about code being low level and verbose, they can read things like Assembly and SPIR-V just fine: visualization is the real issue in that LLMs have no natural understanding of spatial composition through visual comparison because they literally "see" things differently than humans, so the way to get around that is provide them with "visualization" in code form that they can easily reason about and understand, so basically anything that's not deeply nested and has hidden states that they have to reason about.

Also, Flint being stringly typed in JSON is a decision that I don't think I agree with. Looking at the actual spec, this could have just been a TypeScript library, and it would have been 100x better. Using their own example (excuse the formatting):

type SemanticType = "Category" | "YearMonth" | "Profit";

type ChartType = "Heatmap" | "BarChart" | "LineChart" | "ScatterPlot"; // extend as needed

interface ChartEncodings { x: string; y: string; color?: string; size?: string; tooltip?: string; }

interface ChartProperties { colorScheme: string; [key: string]: unknown; // allow other optional properties }

interface ChartSpec { chartType: ChartType; encodings: ChartEncodings; chartProperties: ChartProperties; }

type SemanticTypes = Record<string, SemanticType>;

interface ChartConfig<TData = Record<string, unknown>> { data: TData; semantic_types: SemanticTypes; chart_spec: ChartSpec; }

// The actual typed object literal: const chartConfig: ChartConfig = { data: {}, // replace with your actual data shape/type semantic_types: { game: "Category", period: "YearMonth", newUsers: "Profit", }, chart_spec: { chartType: "Heatmap", encodings: { x: "period", y: "game", color: "newUsers", }, chartProperties: { colorScheme: "redblue", }, }, };