XSLT
1. 개요
XSLT(Extensible Stylesheet Language Transformations)는 XML 문서를 다른 형식으로 변환하기 위한 언어이다. 함수형 프로그래밍 언어, 텍스트 기반 패턴 매칭 언어의 영향을 받았으며, DSSSL을 계승했다.
1999년 XSLT 1.0이 W3C 권고안으로 발표되었으며, 웹 브라우저와 LAMP 환경에서 널리 사용되었다. XSLT 2.0은 XPath 2.0을 기반으로 하며, 정규 표현식, 날짜/시간 함수, 여러 출력 문서, 그룹화, 타입 시스템 강화 등의 기능을 제공한다. XSLT 3.0은 스트리밍 변환, 모듈성 개선, 동적 오류 처리, JSON 지원, 고차 함수 지원 등 주요 기능을 추가했다.
XSLT는 XSLT 프로세서를 통해 XML 소스 문서와 스타일시트를 사용하여 하나 이상의 출력 문서를 생성한다. 선언적 프로그래밍 방식으로, 템플릿 규칙을 통해 특정 패턴과 일치하는 노드를 처리하는 방법을 정의한다. XSLT는 XPath 언어를 사용하여 원본 문서 트리의 부분을 식별하고 연산을 수행하며, XQuery와 기능이 겹치기도 한다.
XSLT 프로세서 구현은 서버 측과 클라이언트 측으로 나뉘며, 다양한 웹 브라우저, 애플리케이션 서버, 라이브러리에서 지원된다. XSLT는 성능 향상을 위해 다양한 최적화 기법을 사용하며, XT-Speedo 벤치마킹 프레임워크를 통해 성능을 측정할 수 있다.
-
XML 기반 프로그래밍 언어 -
VoiceXML
VoiceXML은 음성 브라우저에게 음성 합성, 자동 음성 인식, 대화 관리, 오디오 재생을 지시하는 XML 기반 마크업 언어로서, 다양한 산업 분야에서 음성 인터페이스 구축에 사용되었으며, 관련 표준과 함께 1999년 개발 후 W3C로 표준 관리가 이관되었으나 현재는 새로운 표준 개발이 중단되었다. -
XML 기반 프로그래밍 언어 -
SMIL
SMIL은 멀티미디어 프레젠테이션 제작을 위한 XML 기반 마크업 언어이며, 다양한 미디어 요소를 통합하여 동기화된 프레젠테이션을 만들 수 있도록 지원한다. -
함수형 프로그래밍 언어 -
XQuery
XQuery는 함수형 프로그래밍 패러다임을 지원하며 XPath 식 구문의 상위 집합을 포함하는 XML 데이터 추출 및 조작을 위한 쿼리 언어로서, FLWOR 식을 통해 XML 데이터 조작 및 새로운 XML 문서 구성을 지원하고 XQuery 및 XPath 데이터 모델(XDM)을 기반으로 한다. -
함수형 프로그래밍 언어 -
코틀린 (프로그래밍 언어)
코틀린은 젯브레인즈에서 개발한 정적 타입 언어로, 자바 가상 머신에서 동작하며 자바와의 호환성을 갖고, 안드로이드 공식 지원 언어로 채택되어 다양한 분야에서 활용되고 있으며, 이름은 러시아의 코틀린 섬에서 유래되었다. -
마크업 언어 -
HTML
HTML은 웹 페이지 제작을 위한 표준 마크업 언어로서, 팀 버너스리가 제안하고 구현한 후 인터넷 발전과 함께 널리 사용되며, SGML에 기반하여 하이퍼텍스트 기능으로 다양한 콘텐츠를 표현하고 연결하며, W3C와 WHATWG에서 표준화를 진행하고 최신 버전은 HTML Living Standard이다. -
마크업 언어 -
XAML
XAML은 마이크로소프트에서 개발한 XML 기반의 마크업 언어로, 사용자 인터페이스, 데이터 바인딩, 이벤트 처리 등을 정의하며 WPF, Silverlight, WF, WinRT API 앱, Xamarin.Forms 등에서 UI 개발에 널리 사용된다.
2. 역사
XSLT는 함수형 프로그래밍 언어와 SNOBOL, AWK와 같은 텍스트 기반 패턴 매칭 언어의 영향을 받았다. XSLT의 가장 직접적인 전신은 DSSSL이며, 이는 SGML에 대해 XSLT가 XML에 대해 하는 것과 같은 역할을 했다.
XSLT는 1998년부터 1999년까지 월드 와이드 웹 컨소시엄(W3C)의 확장 가능한 스타일시트 언어 (XSL) 개발 노력의 일부였으며, 이 프로젝트는 XSL-FO와 XPath도 생성했다. 제임스 클라크를 포함한 XSLT를 개발한 표준 위원회 구성원 중 일부는 이전에 DSSSL 작업을 수행했다. XSLT 1.0은 1999년 11월에 W3C 권고안으로 발표되었다.
2001년에 버전 1.1을 만들려는 시도가 실패한 후, XSL 작업 그룹은 XQuery 작업 그룹과 힘을 합쳐 XPath 2.0을 만들었다. 이를 기반으로 마이클 케이가 편집한 XSLT 2.0이 개발되었으며, 2007년 1월에 권고안 상태에 도달했다.
XSLT 3.0은 2017년 6월 8일에 W3C 권고안이 되었다.
2.1. XSLT 1.0
XSLT는 함수형 프로그래밍 언어와 SNOBOL, AWK와 같은 텍스트 기반 패턴 매칭 언어의 영향을 받았다. XSLT의 가장 직접적인 전신은 DSSSL이며, 이는 SGML에 대해 XSLT가 XML에 대해 하는 것과 같은 역할을 했다.
XSLT 1.0은 1998년부터 1999년까지 월드 와이드 웹 컨소시엄(W3C)의 확장 가능한 스타일시트 언어 (XSL) 개발 노력의 일부였으며, 이 프로젝트는 XSL-FO와 XPath도 생성했다. 편집자인 제임스 클라크를 포함한 XSLT를 개발한 표준 위원회 구성원 중 일부는 이전에 DSSSL 작업을 수행했다. XSLT 1.0은 1999년 11월에 W3C 권고안으로 발표되었다. 출시된 지 오래되었음에도 불구하고 XSLT 1.0은 이후 버전이 웹 브라우저 또는 LAMP와 같은 환경에서 기본적으로 지원되지 않기 때문에 여전히 널리 사용되고 있다.
2.2. XSLT 2.0
XSLT는 함수형 프로그래밍 언어와 SNOBOL, AWK와 같은 텍스트 기반 패턴 매칭 언어의 영향을 받았다. XSLT의 가장 직접적인 전신은 DSSSL이며, 이는 SGML에 대해 XSLT가 XML에 대해 하는 것과 같은 역할을 했다.
2001년에 버전 1.1을 만들려는 시도가 실패한 후, XSL 작업 그룹은 XQuery 작업 그룹과 힘을 합쳐 XPath 2.0을 만들었으며, 여기에는 XML 스키마를 기반으로 하는 더 풍부한 데이터 모델과 타입 시스템이 포함되었다. 이를 기반으로 마이클 케이가 편집한 XSLT 2.0이 개발되었으며, 2007년 1월에 권고안 상태에 도달했다. XSLT 2.0의 가장 중요한 혁신은 다음과 같다.
* 정규 표현식을 사용한 문자열 조작
* 날짜, 시간 및 기간을 조작하기 위한 함수 및 연산자
* 여러 개의 출력 문서
* 그룹화 (평면 입력 시퀀스에서 계층 구조 생성)
* 더 풍부한 타입 시스템 및 강력한 타입 검사
2.3. XSLT 3.0
XSLT 3.0은 2017년 6월 8일에 월드 와이드 웹 컨소시엄(W3C) 권고안이 되었다. 주요 새로운 기능은 다음과 같다.
* [[스트리밍 XML|스트리밍 변환]]: 이전 버전에서는 처리 전에 전체 입력 문서를 메모리에 읽어야 했으며, 처리 완료 전까지 출력을 쓸 수 없었다. XSLT 3.0은 XML 스트리밍을 허용하며, 이는 메모리에 맞지 않을 정도로 큰 문서를 처리하거나 XML 파이프라인에서 변환을 연결할 때 유용하다.
* 대규모 스타일시트의 모듈성을 개선하기 위한 패키지.
* xsl:try 명령을 사용하여 동적 오류를 개선된 처리.
* XSLT가 XML뿐만 아니라 JSON도 처리할 수 있도록 맵과 배열 지원.
* 함수를 다른 (고차) 함수의 인수로 사용할 수 있다.
3. XSLT 처리 모델
--
XSLT는 XML 원본 문서와 XSLT 스타일시트를 입력으로 받아 문서를 출력한다. XSLT 스타일시트는 템플릿 룰:명령어(template rules: instructions)와 프로세서가 출력 문서를 제작하는 데 필요한 지침을 담고 있다.
XSLT는 선언적 프로그래밍 언어이다. 템플릿 룰은 조건에 따라 어떤 동작을 수행하는지 나열하는 대신, 지정한 XPath 형태의 패턴과 일치하는 노드를 어떻게 처리할지를 정의한다. 템플릿은 프로세서가 패턴을 결과 트리 형태로 나타낼 수 있는 표현식을 담고 있다.
일반적인 프로세서는 먼저 스타일 시트를 읽고 준비한 다음, 입력 XML 문서에서 소스 트리를 구축한다. 그 후 소스 트리의 루트 노드를 처리하고, 스타일시트에서 해당 노드에 가장 잘 맞는 템플릿을 찾아 템플릿 내용을 평가한다. 각 템플릿의 지침은 결과 트리에 노드를 만들거나, 소스 트리의 더 많은 노드를 처리하도록 지시한다. 마지막으로 결과 트리는 XML 또는 HTML 텍스트로 직렬화된다.
3.1. 구성 요소
XSLT 처리의 구성 요소는 다음과 같다.
* 하나 이상의 XML 원본 문서
* 하나 이상의 XSLT 스타일시트 모듈
* XSLT 템플릿 처리 엔진(프로세서)
* 하나 이상의 결과 문서
XSLT는 일반적으로 XML 원본 문서와 XSLT 스타일시트를 입력으로 받아 문서를 출력한다. XSLT 스타일시트는 템플릿 룰:명령어(template rules: instructions)와 프로세서가 출력 문서를 제작하는 데 필요한 지침을 담고 있다.
3.2. 템플릿 규칙 처리
XSLT는 선언적인 언어이다. 템플릿 규칙은 조건에 따라 어떤 동작을 수행하는지 나열하는 대신, 지정한 XPath 형태의 패턴과 일치하는 노드를 어떻게 처리할지를 정의한다. 템플릿은 프로세서가 패턴을 결과 트리 형태로 나타낼 수 있는 표현식을 담고 있다.
프로세서는 고정된 알고리즘을 따른다. 스타일시트는 이미 읽어와서 준비되어 있고, 프로세서는 입력 XML 문서에서 원본 트리를 만든다. 원본 트리의 루트 노드부터 스타일시트에서 가장 잘 맞는 템플릿을 찾아 변환한다. 각 템플릿의 명령어는 결과 트리의 노드를 생성하거나, 원본 트리의 다음 노드를 처리하도록 지시한다.
--
널리 구현된 명령형 프로그래밍 언어인 C와 달리, XSLT는 선언적 프로그래밍이다. 기본 처리 패러다임은 패턴 매칭이다. 상태 저장 환경에서 수행할 명령형 작업 시퀀스를 나열하는 대신, 템플릿 규칙은 프로세서가 특정 XPath와 유사한 패턴과 일치하는 노드를 발견할 경우 해당 노드를 처리하는 방법만 정의하며, 템플릿의 내용은 효과적으로 평가된 형태, 즉 프로세서의 출력 기반인 결과 트리를 직접 나타내는 함수형 프로그래밍 식을 구성한다.
일반적인 프로세서는 다음과 같이 동작한다. 먼저, 스타일시트가 이미 읽혀지고 준비되었다고 가정하면, 프로세서는 입력 XML 문서에서 소스 트리를 구축한다. 그런 다음 소스 트리의 루트 노드를 처리하고 스타일시트에서 해당 노드에 가장 잘 일치하는 템플릿을 찾아 템플릿의 내용을 평가한다. 각 템플릿의 지침은 일반적으로 프로세서가 결과 트리에 노드를 만들거나 루트 노드와 동일한 방식으로 소스 트리의 더 많은 노드를 처리하도록 지시한다. 마지막으로 결과 트리는 XML 또는 HTML 텍스트로 직렬화된다.
3.3. 프로세서 구현
XSLT 프로세서 구현은 크게 서버 측과 클라이언트 측으로 나뉜다. 클라이언트 XSLT 프로세싱은 1999년부터 Microsoft Internet Explorer에서 가능했지만, XSLT를 지원하지 않는 이전 브라우저와 다른 브라우저가 널리 퍼져 있어 도입 속도가 느렸다. 비슷한 이유로 XSLT 2.0의 도입도 제한되어 있다.
XSLT 프로세서는 단일 제품으로 제작되거나, 웹 브라우저, 애플리케이션 서버, Java나 .NET 등 프레임워크 또는 운영체제의 컴포넌트로 제작된다.
* Altova의 RaptorXML은 XMLSpy 개발 툴킷에서 사용 가능하며, REST 인터페이스를 사용하여 호출되는 독립 실행형 서버 구현으로 제공되는 XSLT 3.0 프로세서이다.
* IBM은 Datapower 브랜드로 특수 목적 하드웨어 어플라이언스에 내장된 XSLT 처리를 제공한다.
* libxslt는 상업용 애플리케이션에서 재사용할 수 있는 MIT 라이선스로 출시된 자유 소프트웨어 라이브러리이다. libxml을 기반으로 하며 속도와 이식성을 위해 C로 구현되었다. XSLT 1.0 및 EXSLT 확장을 지원한다.
* macOS 및 많은 리눅스 배포판에 포함된 `xsltproc`를 통해 명령줄에서 사용할 수 있으며, Cygwin을 통해 Windows에서도 사용할 수 있다.
* Safari 및 Chrome 웹 브라우저에서 각각 사용되는 WebKit 및 Blink 레이아웃 엔진은 XSL 변환을 수행하기 위해 libxslt 라이브러리를 사용한다.
* 바인딩은 Python, Perl, Ruby, PHP, Common Lisp, Tcl, 및 C++.에 존재한다.
* Microsoft는 두 개의 XSLT 프로세서(모두 XSLT 1.0만)를 제공한다. 이전 프로세서인 MSXML은 COM 인터페이스를 제공하며, MSXML 4.0부터는 명령줄 유틸리티 `msxsl.exe`도 포함한다. .NET 런타임은 `System.Xml.Xsl` 라이브러리에 별도의 내장 XSLT 프로세서를 포함한다.
* Saxon은 독립 실행형 작동 및 Java, JavaScript 및 .NET을 위한 오픈 소스 소프트웨어 및 독점 소프트웨어 버전이 있는 XSLT 3.0 및 XQuery 3.1 프로세서이다. 별도의 제품인 Saxon-JS는 Node.js 및 브라우저에서 XSLT 3.0 처리를 제공한다.
* [https://github.com/egh/xjslt xjslt]는 Node.js와 브라우저를 지원하는 JavaScript용 오픈 소스 소프트웨어 XSLT 2.0 컴파일러이다.
* Xalan은 Java 및 C++에서 사용할 수 있는 Apache Software Foundation의 오픈 소스 XSLT 1.0 프로세서이다. Xalan 프로세서의 변형은 Oracle의 표준 Java 배포판에 기본 XSLT 프로세서로 포함되어 있다.
* 웹 브라우저: Safari, Chrome, Firefox, Opera 및 Internet Explorer는 모두 XSLT 1.0(만)을 지원한다. 브라우저는 XML 파일의 즉석 변환을 수행하고 변환 출력을 브라우저 창에 표시할 수 있다. 이는 XML 문서에 XSL을 임베딩하거나 XML 문서에서 XSL 지침을 포함하는 파일을 참조하여 수행된다. 후자는 보안 모델 때문에 로컬 파일 시스템의 파일에서 Chrome에서는 작동하지 않을 수 있다.
* Adobe AXSLE 엔진, 독점 라이브러리
4. XPath
XSLT는 원본 문서 트리의 부분을 식별하고 연산을 수행하기 위해 XPath 언어를 사용한다. XPath는 또한 XSLT 자체에서 더 확장하는 다양한 함수를 제공한다.
XSLT 1.0은 XPath 1.0을 사용하고, XSLT 2.0은 XPath 2.0을 사용하며, XSLT 3.0은 XPath 3.0 또는 3.1과 함께 작동한다. 1.0 및 2.0의 경우 XSLT와 XPath 사양이 같은 날짜에 게시되었다. 그러나 3.0의 경우 더는 동기화되지 않았다. XPath 3.0은 2014년 4월에 권고안이 되었고, 그 뒤를 이어 2017년 2월에 XPath 3.1이 발표되었으며, XSLT 3.0은 2017년 6월에 발표되었다.
5. XQuery 비교
XSLT의 기능은 다량의 XML 문서의 쿼리 언어로 사용되는 XQuery와 겹친다.
XSLT 2.0과 XQuery 1.0 표준은 W3C의 별도 작업 그룹이 개발하였으며, 접근 방식을 통일하기 위해 협업하였다. 이들은 데이터 모델, 타입 시스템, 함수 라이브러리를 공유하며, 둘 다 XPath 2.0을 보조 언어로 사용한다.
두 언어는 서로 다른 환경의 요구를 반영한다. XSLT는 주로 화면, 웹(웹 템플릿 언어), 인쇄물로 사람이 XML을 읽을 수 있게 처리하는 것이 주요 목적이다. XQuery는 주로 SQL 전통에서 데이터베이스 쿼리 언어로 여겨진다.
XSLT는 더 유연한 구조를 가진 서술형 문서 처리에 강하며, XQuery는 관계형 조인을 수행하는 경우와 같이 데이터 처리에 더 강하다는 점에서 차이가 있다.
6. 미디어 유형
XSLT영어 2.0이 출시되면서 W3C는 2007년에 MIME 미디어 유형 `application/xslt+xml`의 등록을 권장했고, 이후 인터넷 할당 번호 기관에 등록되었다.
XSLT영어 1.0 이전 작업 초안에서는 임베딩 예제에 `text/xsl`을 사용했으며, 이 유형은 인터넷 익스플로러 및 MSXML영어(2012년경)에서 마이크로소프트에 의해 구현되고 계속 홍보되었다. 또한 다른 브라우저에서도 `xml-stylesheet` 처리 지침에서 널리 인식되었다. 따라서 실제로 이 처리 지침을 사용하여 브라우저에서 변환을 제어하려는 사용자는 이 등록되지 않은 미디어 유형을 사용할 수밖에 없었다.
XSLT영어의 미디어 유형은 "`application/xslt+xml`"로 [[인터넷 할당 번호 기관영어에 등록되어 있으며, "`application/xslt+xml`" 또는 "`application/xml`"이 바람직한 MIME 유형이다. 그러나, 인터넷 익스플로러 등 일부 사용자 에이전트는 이러한 MIME으로는 XSLT영어를 인식하지 못하거나, "`text/xsl`" 등의 독자적으로 정한 MIME만을 인식하는 경우도 많다.
7. XSLT 예제
XSLT는 XML 형식의 데이터를 다양한 형식으로 변환하는 데 사용될 수 있다. 다음은 변환 전 XML 문서의 예시이다.
```xml
```
XSLT를 이용하면 위의 XML 데이터를 XML, XHTML, CSV 등 다양한 형식으로 변환할 수 있다. 각 형식 변환에 대한 예시는 하위 섹션을 참조하면 된다.
7.1. XML에서 XML로 변환
XSLT는 XML 형식의 데이터를 다양한 형식의 데이터로 변환할 수 있다. 다음은 그 예시를 보여준다.
변환 전 XML
```xml
```
| 변환 후 형식 | XSLT 코드 | 변환 결과 |
|---|---|---|
| XML | ||
| XHTML | ||
| CSV |
7.2. XML에서 XHTML로 변환
다음은 XML 입력 파일을 XHTML로 변환하는 예시이다.
```xml
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/1999/xhtml">
Persons
```
위의 XSLT 파일을 사용하여 XML 입력 파일을 처리하면 다음과 같은 XHTML 파일이 생성된다. (가독성을 위해 공백은 조정되었다.)
```xml
Persons
- Ismincius, Morka
- Smith, John
```
이 XHTML 문서는 웹 브라우저에서 다음과 같이 렌더링된다.
--
웹 브라우저가 표시 중인 XML 문서에 XSL 변환을 적용할 수 있도록, XML 스타일시트 처리 지침을 XML에 삽입할 수 있다. 예를 들어, 위의 스타일시트가 "example2.xsl"로 제공되는 경우, 다음 지침을 XML에 추가할 수 있다.
```xml
```
이 예에서 `text/xsl`은 W3C 사양에 따르면 기술적으로 정확하지 않지만 (유형은 `application/xslt+xml`이어야 한다고 명시), 2009년 현재 브라우저에서 널리 지원되는 유일한 미디어 유형이며, 2021년에도 상황은 변하지 않았다.
다음은 XSLT를 사용하여 XML 형식의 데이터를 XHTML 형식으로 변환하는 예시이다.
| 변환 후 형식 | XSLT 코드 | 변환 결과 |
|---|---|---|
| XHTML |
7.3. XML에서 CSV로 변환
XML 형식의 데이터를 다양한 형식의 데이터로 변환할 수 있다. 다음은 그 예시이다.
변환 전 XML은 다음과 같다.
```xml
```
| 변환 후 형식 | XSLT 코드 | 변환 결과 |
|---|---|---|
| CSV |
8. 템플릿 함수
XSLT는 템플릿 함수를 재귀적인 형태로 정의할 수 있는 순수 함수형 언어이기도 하다.
다음은 템플릿 함수 `String_replaceAll`이다. 이 함수는 매개변수 `this`로 지정된 문자열 내에서 매개변수 `substring`으로 지정된 부분 문자열을 모두 매개변수 `replacement`로 지정된 문자열로 대체한 문자열을 반환한다.
이 예시를 통해 다음 사항을 알 수 있다.
* 템플릿 함수 정의 방법 (`xsl:template`, `xsl:param`)
* 인자 값 참조 방법 (`$인자명`)
* 조건 분기 방법 (`xsl:if`, `xsl:choose`)
* XSLT 함수 (`not`, `contains`, `substring-before`, `substring-after`)
* XSLT 함수 사용 방법 (`
* 정의된 템플릿 함수 호출 방법 (`xsl:call-template`, `xsl:with-param`: 재귀 호출 부분)
```xml
9. 프로세서 구현체
XSLT 프로세서 구현은 크게 서버 측과 클라이언트 측으로 나뉜다. 클라이언트 XSLT 프로세싱은 1999년부터 Microsoft Internet Explorer에서 가능하지만, XSLT를 지원하지 않는 이전 브라우저와 다른 브라우저가 널리 퍼져 있어 도입 속도가 느리다. 비슷한 이유로 XSLT 2.0의 도입도 제한되어 있다.
XSLT 프로세서는 단일 제품으로 제작되거나, 웹 브라우저, 애플리케이션 서버, Java나 .NET 등 프레임워크 또는 운영체제의 컴포넌트로 제작된다.
* Altova의 RaptorXML은 XMLSpy 개발 툴킷에서 사용 가능하며, REST 인터페이스를 사용하여 호출되는 독립 실행형 서버 구현으로 제공되는 XSLT 3.0 프로세서이다.
* IBM은 Datapower 브랜드로 특수 목적 하드웨어 어플라이언스에 내장된 XSLT 처리를 제공한다.
* libxslt는 상업용 애플리케이션에서 재사용할 수 있는 MIT 라이선스로 출시된 자유 소프트웨어 라이브러리이다. libxml을 기반으로 하며 속도와 이식성을 위해 C로 구현되었다. XSLT 1.0 및 EXSLT 확장을 지원한다.
* macOS 및 많은 리눅스 배포판에 포함된 `xsltproc`를 통해 명령줄에서 사용할 수 있으며, Cygwin을 통해 Windows에서도 사용할 수 있다.
* Safari 및 Chrome 웹 브라우저에서 각각 사용되는 WebKit 및 Blink 레이아웃 엔진은 XSL 변환을 수행하기 위해 libxslt 라이브러리를 사용한다.
* 바인딩은 Python, Perl, Ruby, PHP, Common Lisp, Tcl, 및 C++.에 존재한다.
* Microsoft는 두 개의 XSLT 프로세서(모두 XSLT 1.0만)를 제공한다. 이전 프로세서인 MSXML은 COM 인터페이스를 제공하며, MSXML 4.0부터는 명령줄 유틸리티 `msxsl.exe`도 포함한다. .NET 런타임은 `System.Xml.Xsl` 라이브러리에 별도의 내장 XSLT 프로세서를 포함한다.
* Saxon은 독립 실행형 작동 및 Java, JavaScript 및 .NET을 위한 오픈 소스 소프트웨어 및 독점 소프트웨어 버전이 있는 XSLT 3.0 및 XQuery 3.1 프로세서이다. 별도의 제품인 Saxon-JS는 Node.js 및 브라우저에서 XSLT 3.0 처리를 제공한다.
* [https://github.com/egh/xjslt xjslt]는 Node.js와 브라우저를 지원하는 JavaScript용 오픈 소스 소프트웨어 XSLT 2.0 컴파일러이다.
* Xalan은 Java 및 C++에서 사용할 수 있는 Apache Software Foundation의 오픈 소스 XSLT 1.0 프로세서이다. Xalan 프로세서의 변형은 Oracle의 표준 Java 배포판에 기본 XSLT 프로세서로 포함되어 있다.
* 웹 브라우저: Safari, Chrome, Firefox, Opera 및 Internet Explorer는 모두 XSLT 1.0(만)을 지원한다. 브라우저는 XML 파일의 즉석 변환을 수행하고 변환 출력을 브라우저 창에 표시할 수 있다. 이는 XML 문서에 XSL을 임베딩하거나 XML 문서에서 XSL 지침을 포함하는 파일을 참조하여 수행된다. 후자는 보안 모델 때문에 로컬 파일 시스템의 파일에서 Chrome에서는 작동하지 않을 수 있다.
* Adobe AXSLE 엔진, 독점 라이브러리
10. 성능
초창기 대부분의 XSLT 프로세서는 인터프리터 방식이었다. 최근에는 코드를 생성하는 방식이 점점 더 일반화되고 있으며, 자바 바이트코드나 .NET 공용 중간 언어와 같은 이식 가능한 중간 언어를 대상으로 사용한다. 그러나 인터프리터 제품조차도 일반적으로 별도의 분석 및 실행 단계를 제공하여 최적화된 표현식 트리를 메모리에 생성하고 여러 변환을 수행하기 위해 재사용할 수 있도록 한다. 이는 동일한 변환이 초당 여러 번 다른 소스 문서에 적용되는 온라인 게시 애플리케이션에서 상당한 성능 이점을 제공한다. 이러한 분리는 XSLT 처리 API (JAXP 등)의 설계에 반영되어 있다.
초창기 XSLT 프로세서는 최적화 기능이 거의 없었다. 스타일시트 문서를 문서 객체 모델로 읽어 들여 프로세서가 직접 작동했다. XPath 엔진 역시 최적화되지 않았다. 그러나 XSLT 프로세서는 점점 더 함수형 프로그래밍 언어 및 데이터베이스 쿼리 언어에서 발견되는 최적화 기법을 사용하고 있는데, 예를 들어 표현식 트리의 정적 재작성(예: 루프 밖으로 계산 이동), 게으른 파이프라인 평가를 통해 중간 결과의 메모리 사용량을 줄이는 방식(프로세서가 모든 하위 표현식을 완전히 평가하지 않고 `following-sibling::*[1]`과 같은 표현식을 평가할 수 있을 때 "조기 종료" 허용) 등이 있다. 많은 프로세서들은 또한 범용 DOM 구현보다 훨씬 더 효율적인(공간 및 시간 모두에서) 트리 표현을 사용한다.
2014년 6월, 데비 로켓과 마이클 케이는 XT-Speedo라는 XSLT 프로세서용 오픈 소스 벤치마킹 프레임워크를 소개했다.