Why We Built HQL, the ASAM ODS Query Language | Page: 4 of 4 | Previous: Page 3: ASAM ODS Access from Python, MATLAB, and REST

HQL turns querying ASAM ODS data into self-service test data access, so the engineers who need answers can get them without waiting on a developer. The earlier pages showed that querying ASAM ODS data through the raw API is legitimate but demanding, that HQL replaces a page of API code with one readable line, and that the same language reaches Java, the command line, MATLAB, REST, Python, and the browser. This page is the reason all of that matters. It explains why a purpose-built query language speeds up development and puts test data directly in the hands of the people who use it, through four concrete mechanisms, an easy learning curve, a simpler query than the raw alternative, comfort functions that speak the engineer's own language, and a value chain that ends in lower cost and faster results.

HQL delivers self-service test data access by letting engineers write their own queries in a language they already half-know, instead of routing every data request through the one developer who understands the ASAM ODS API. That shift depends first on how quickly an engineer can become productive, and HQL is deliberately easy to learn.

It is SQL-like, using familiar select, where, join, and order-by patterns, so an engineer who can read a SELECT statement already recognizes the shape of an HQL query. It is not literally SQL, because it uses an object-oriented syntax fitted to the ASAM ODS data model rather than to relational tables, but the intuition transfers almost directly.

In HighQSoft's experience, engineers who already write SQL are productive in HQL within about half a day, which is the difference between a capability a team can actually adopt and one that stays locked behind a specialist. When the learning cost is that low, self-service stops being aspirational and becomes the normal way people get data, which is the whole point of building the language in the first place.

The simplest way to see why HQL speeds up development is to compare one HQL line against the raw query format it replaces. The ASAM ODS 6 REST API accepts queries as a JSON filter document, where selecting a few attributes and filtering by a name pattern means writing a nested structure of objects and operators.

The same conceptual query, selecting identifying attributes and filtering by a name wildcard, is one line of HQL.

The difference is structural, not a matter of taste. The JSON document is the standard's own raw query format, exposed directly, and it requires the author to nest attributes, filter, condition, operator, and value correctly across several levels for even a basic request. The HQL line reads left to right the way a person would describe the request out loud.

Less to write means less to get wrong, less to review, and less to maintain when the request changes, and that saved effort repeats on every query a team writes. This comparison is against the standard's raw JSON format, not against any particular vendor, and the point is only that a one-line query language removes a layer of hand-built structure that a JSON document leaves in place.

HQL's comfort functions let engineers ask questions of ASAM ODS data in their own terms, which is what keeps self-service from turning into a new kind of specialist work. The most important of these is business-language access. HQL loads the application model, so an engineer queries using their organization's own element and attribute names, the domain vocabulary they already use to talk about their tests, rather than the generic base-model types and identifiers the raw API works in. The same query text stays readable to the people who own the data, because it is written in their language, not the API's.

Inline unit conversion is the second comfort function. An engineer names the target unit in square brackets after a channel and HQL converts the values as it returns them, so a length can come back in miles or a duration in hours without any surrounding conversion code.

Date arithmetic is the third. Functions such as a relative "seven days ago" expression compute times inside the query itself, so asking for everything recorded in the last week does not require precomputing timestamps in the calling code. Each of these removes work that would otherwise land in downstream scripts, and together they mean the query says what the engineer means, in the engineer's own words.

Self-service HQL access lowers cost and speeds up results by breaking the bottleneck that forms when ASAM ODS data access depends on scarce specialists. The mechanisms build on each other. Simpler queries, a familiar SQL-like syntax, the engineer's own business language, and one language that works across every tool a team already uses all add up to the same outcome, which is that engineers serve themselves instead of filing a development ticket for each new question.

For the individual engineer, that means an answer in minutes rather than a wait in a queue. For the team, it means the one or two developers fluent in the ODS API stop being a data-request help desk and get their time back for the work only they can do, while the team maintains far less custom access code, because there is far less of it to write.

For the organization, the arithmetic is straightforward. Less developer time spent on data plumbing is lower cost, and faster answers are faster results, across every project that touches test data. Development that used to stall waiting on a custom access layer simply moves forward. That is the benefit behind every feature in this series, and it is the reason HighQSoft built HQL rather than living with the API cost like everyone else. It is, in the end, simply the faster way to move forward.

Self-service does not stop at engineers who write queries. HighQSoft's MCP Server for ASAM ODS connects AI assistants such as Claude or ChatGPT to the same governed test data, so anyone on the team can ask questions in plain English while the assistant writes the HQL. For teams going the AI route, the language the assistant generates matters. Language models have seen enormous amounts of SQL, so a one-line SQL-like query plays to what they already do well, whereas the nested JSON query document shown above leaves a model far more structure to get exactly right. And when a generated query does need correcting, HQL responds with error messages a model or a person can read and act on, which keeps the generate-and-correct loop short. Every AI-generated query still runs against the same ODS server, under the same access rights, as every other query in this series. The plain-English layer itself is covered in HighQSoft's natural-language ASAM ODS query guide.

HighQSoft makes it easy to see the benefit of self-service test data access for yourself, at whatever level of commitment fits your team. Start free and hands-on by trying HQL interactively against sample data through pyHQL or the command line, or open the HQL query language product page for the full capability list. When you want to see it on your own model, request a demo of HQL running against your application model, or work through HighQSoft's proof-of-concept guide for test data management for a structured evaluation. For a guided technical session on pyHQL, matHQL, or the HQL Web Service, contact HighQSoft directly. To revisit how the same language reaches every tool your team uses, return to ASAM ODS access from Python, MATLAB, and REST.