XSLT Sorting with xsl:sort

 Sorting is a very common requirement in XSLT transformations. XSLT gives us the xsl:sort instruction for this. It works inside xsl:for-each and inside xsl:apply-templates. While working on integration scenarios, I have used almost every option of xsl:sort. I thought of writing a blog post so others can easily find examples as well.

Basic Sorting

The xsl:sort instruction must be the first child of xsl:for-each. The select attribute defines the sort key.

<employees>    
   <employee>        
     <name>Nimal</name>
        <salary>85000</salary>
        <department>Finance</department>
    </employee>
    <employee>
        <name>Amara</name>
        <salary>92000</salary>
        <department>Engineering</department>
    </employee>
    <employee>
        <name>Kasun</name>
        <salary>78000</salary>
        <department>Engineering</department>
    </employee>
</employees>

Sort by name:

Why API Gateways Are Not Enough for the AI Era

For many years, whenever we needed to control traffic between applications, we had one clear answer. Put an API gateway in front of it. It worked well. But in 2026, our applications are not the only consumers anymore. AI agents are calling models (GPT, Claude, etc), calling tools, and even calling other agents. Recently, I spent some time looking into how to govern this new kind of traffic. I realised that our traditional API gateways are not ready for it.

In this post, I am going to walk through what AI gateways are, the three types you will see in the market, and why you should not force your existing API gateway into this role. I will also cover a common question at the end. If your API needs are simple, can one AI gateway do both jobs?

What is an AI gateway?

An AI gateway is a middleware layer. It sits between an AI agent and whatever the agent is calling. It enforces identity, policy, cost control, and safety at that boundary. 

The market terminology is confusing. Different vendors use different names for the same thing. The simple way I think about it is to classify each gateway by its target: 

• Model/LLM gateway:  when the target is a model or LLM 
• MCP gateway: when the target is a tool exposed over MCP 
• Agent gateway: when the target is another agent 

"AI gateway" is just a term for all above three. The common idea is this, wherever governance changes are needed, you need a control point. 

Designing APIs for AI agents

For many years, we designed APIs for two kinds of consumers, human developers and other applications. In 2026, there is a third consumer, and it is growing fast. AI agents. As you already know, most developers now use AI in their day to day work, but only a small number of teams design their APIs with AI agents in mind. This gap is a big problem, and also a big opportunity.

In this post, I will share what I think changes when an AI agent calls your API, and what you can do about it.

What is an AI agent?

An AI agent is a program powered by a large language model (LLM) that can take actions on its own. For example, an agent can:

• Search insurance quotes from different providers and compare policies
• Read your support tickets and reply to customers
• Pull sales data from three systems and build a report

To do these things, the agent needs to call APIs. Your APIs.

How agents are different from human developers

A human developer reads your documentation multiple times, writes code, tests it, and deploys. An agent works differently:

1. Agents read your API in real time.

An agent does not spend a week studying your docs. It looks at your API description at the moment it needs it. If your endpoint names and descriptions are unclear, the agent will make mistakes.

2. Agents call APIs at machine speed.

One agent can make hundreds of calls in a minute. It can also retry in loops if something goes wrong. Your rate limits and error handling need to be ready for this.

3. Agents cannot ask you questions.

A developer can email you when the docs are confusing. But an AI agent cannot. Everything the agent needs must be in the API contract itself.

4. Agents follow instructions literally.

If your error message says "try again later", an agent may try again every second, may be forever. Clear, specific responses are more important now.

All New HTTP QUERY Method - RFC-10008

For a very long time, whenever I needed to send a query to a server, I had only two real options: GET or POST. Both worked. Based on personal preference, some prefer to use the HTTP GET method and others prefer HTTP POST. Recently, while going through the newly published RFC 10008, I came across a new HTTP method called QUERY that finally fills this gap. In this post, I am going to walk through what it is, why we need it, and how it actually works.

The problem with GET and POST

The most common way to send a query is to encode everything into the URL query parameters and send a GET request.

GET /feed?q=foo&limit=10&sort=-published HTTP/1.1

Host: example.org

This is clean and works well for most use cases, until your system grows.

1. URLs have practical size limits. HTTP itself doesn't define a maximum URI length, but every system our request goes through has its own limits. Browsers, servers, proxies, load balancers, and CDNs all impose their own limits. Based on the RFC, it's said to be 8 KB. If any of these underlying systems has a URI limit, our request can be rejected with 414 URI Too Long.
2. Encoding. When working with nested filters, arrays, JSON, or query parameters with spaces, quotes, or Unicode, it is more prone to data-handling issues and even a nightmare to debug and isolate a real production issue.
3. Sensitive data exposure. URIs are far more likely to be logged in browser history or saved in bookmarks than the request body, so putting sensitive data there is risky.
4. Caching issues. For a GET request, the cache uses the full URL as the label for each stored response. The cache only reuses a stored response if the URL matches exactly; it doesn't understand if the user sends the same query parameters in a different order. Because of this, there will be fewer cache hits and wasted cache storage.