XSLT Conditional Logic: if, choose, when and otherwise

In XSLT (Extensible Stylesheet Language Transformations), we often need to produce different output based on conditions. XSLT gives us two main instructions for this. The xsl:if instruction and the xsl:choose instruction. In XSLT 2.0 or later, we also have a shorter inline syntax. I thought of writing a blog post so others can easily find examples as well.

xsl:if Instruction

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.

<?xml version="1.0" encoding="UTF-8"?>

<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.