The Many Languages of Data: How .NET Learned to Speak in Formats
It's a Tuesday afternoon and you're debugging a feature that touches four different pieces of data. First, you write a SQL query to pull a customer record from the database. Then you filter an in-memory list of orders using LINQ. Then you parse a JSON payload from a third-party API, reaching for dot-notation and the occasional JSONPath expression. Finally, you open a legacy XML configuration file and, out of muscle memory, write an XPath query to find the node you need.
Four data problems. Four different "languages" to solve them. You didn't think twice about switching between SQL, LINQ, JSON traversal, and XPath — because as a .NET developer, this kind of context-switching is just Tuesday.
This series is about naming that pattern, understanding where it came from, and figuring out what to do with it.
Format vs. Language: Two Different Things
It's worth being precise about two words that get used loosely: format and language.
A data format is a shape — a way of structuring data so it can be stored or transmitted. CSV is rows of comma-separated values. JSON is nested objects and arrays. A relational database is tables with rows and typed columns. A graph is nodes and edges. XML is a tree of tagged elements. These are all answers to the question "how is this data arranged?"
A data language, on the other hand, is a way of asking questions about that shape. Once your data is arranged as a relational table, SQL lets you filter, join, and aggregate it. Once it's arranged as an XML tree, XPath lets you navigate down branches and select nodes. Once it's a JSON document, you reach for dot-notation, JsonDocument, or JSONPath. The format is the noun; the language is the verb.
This distinction matters because it explains something that otherwise looks like accidental complexity in the .NET ecosystem: the reason you juggle so many query syntaxes isn't that Microsoft (or the industry) failed to standardize things. It's that each shape of data has fundamentally different operations that make sense on it — and those operations tend to calcify into their own dialect.
Why Every Format Grows Its Own Language
Think about what it actually means to "navigate" each shape:
- A relational table is built on set theory. The natural operations are filtering rows, joining sets, grouping, and aggregating. SQL's SELECT, JOIN, and GROUP BY are set operations wearing English words.
- An XML or JSON document is a tree. The natural operations are descending into children, selecting by path, and matching patterns along a hierarchy. XPath's //book[@category='fiction'] and JSONPath's $.store.book[?(@.price < 10)] are tree-traversal operations.
- A graph (social networks, recommendation engines, knowledge graphs) is nodes and relationships. The natural operations are traversing edges and finding paths. GraphQL and graph-database query languages like Gremlin or Cypher are built around "start here, follow this relationship, stop when."
- Objects in memory are, well, objects — instances with properties and methods, often in collections. The natural operations are the functional-programming staples: filter, map ('Select'), and reduce ('Aggregate').
Each of these languages exists because someone looked at a shape of data, asked "what would make navigating this feel natural?", and built a syntax around the answer. SQL wasn't designed for trees. XPath wasn't designed for sets. You can force one language to do another's job — plenty of developers have written tortured XPath to simulate a join — but it always feels like it, because the underlying math doesn't match the shape.
This is the pattern worth carrying through the rest of this series: the proliferation of query languages in .NET isn't clutter. It's specialization.
A Short History, Through the .NET Lens
.NET's own history is a decent map of the industry's broader shift in how we store and query data. Here's the abbreviated tour.
The flat-file era
Before frameworks gave you much help, data interchange often meant CSV or tab-delimited text — log files, exports, batch feeds. Early .NET developers reached for 'StreamReader', 'String.Split', and a lot of manual parsing. There was no real "language" here, just string manipulation, because the format itself was barely structured. The closest thing to a query language was a for loop and a regular expression.
RDBMS dominance and ADO.NET
For most of .NET's early life, the relational database was the center of gravity. ADO.NET gave you SqlConnection, SqlCommand, and DataReader, but the real language was SQL itself — written as raw strings, embedded in C# code, often in stored procedures to keep logic out of the application tier. This was the first place .NET developers learned that the query language lives closer to the data than to the code.
The XML decade
The 2000s were XML's moment in enterprise .NET. SOAP web services, app.config and web.config files, XSD schema validation, and document interchange all leaned on XML. This gave rise to a whole toolkit: XmlDocument, later XDocument and LINQ to XML, plus XPath for navigating trees and XQuery for more complex tree-shaped queries. If you worked in enterprise .NET during this period, XPath syntax is probably still burned into your fingers.
The JSON shift
As REST APIs replaced SOAP and JavaScript-heavy front ends became the norm, JSON overtook XML as the default interchange format — lighter, easier to parse, a more natural fit for JavaScript clients. .NET's answer evolved too: Newtonsoft.Json (Json.NET) dominated for years as the de facto standard, and Microsoft eventually shipped its own high-performance System.Text.Json. The "language" here is less a formal query syntax and more a set of patterns: strongly-typed deserialization, dynamic and JObject for loosely-typed access, and JSONPath for ad hoc querying of large documents.
NoSQL and document stores
As applications outgrew rigid relational schemas, document databases like MongoDB and Azure Cosmos DB introduced yet another dialect — one that often looks like SQL but behaves differently underneath, optimized for querying semi-structured, schema-flexible documents rather than strictly typed rows. Cosmos DB's query language is a good example: SQL-shaped syntax bolted onto a JSON-document model, which is exactly what you'd expect once you internalize that language mirrors format.
Graph data
More recently, graph-shaped problems — social connections, recommendation engines, fraud detection, knowledge graphs — have pushed a new format into the mainstream, and with it, new languages. GraphQL (despite the name, more an API query language than a graph-database language) has become common in .NET APIs via libraries like HotChocolate. True graph databases like Neo4j bring their own traversal languages, like Cypher, into projects that need them.
LINQ: Microsoft's attempt at a universal answer
Threaded through all of this is LINQ (Language Integrated Query), introduced in .NET 3.5 — arguably Microsoft's most ambitious attempt to paper over the fragmentation. The idea: give developers one query syntax — from, where, select, or the fluent .Where(), .Select() — and let different providers translate that syntax into the native language underneath. LINQ to Objects operates on in-memory collections. LINQ to SQL and later Entity Framework's LINQ provider translate the same syntax into SQL. LINQ to XML operates on XML trees.
It's a genuinely clever piece of engineering, and it's why a huge number of .NET developers can go weeks without writing raw SQL or XPath by hand. But — and this is where Part 3 of this series will dig in — it's an abstraction, not a unification. The translation isn't always perfect, and knowing where it leaks is part of being effective with it.
What's Next
That's the shape of the territory: a handful of data formats, each with a language that grew out of its underlying structure, and .NET's evolving relationship with all of them — culminating in LINQ's attempt to give developers one syntax to rule them all.
In Part 2, we'll go format by format — CSV, RDBMS, XML, JSON, document databases, graphs, binary formats, and in-memory objects — with concrete .NET code for each, so you have a working field guide rather than just a history lesson.
In Part 3, we'll come back to LINQ and ask the harder question: how far can one language really abstract over this many fundamentally different shapes of data — and where is that abstraction starting to show its seams, especially as vector databases and embeddings introduce yet another format (and yet another language) into the mix.
That’s all for now. May your intention be clear and your mind be still. With this quiet wish, I rest my pen and return to the silence.