Z mixed content mamy do czynienia wtedy gdy węzłami potomnymi danego węzła są zarówno węzły typu text() jak i węzły typu node() - np.:

<foo>foo<bar> bar </bar>text</foo> 

Dla powyższego XMLa nie istnieje możliwość wypisania napisu bedącego bezpośrednim potomkiem węzła foo za pomocą prostego <xsl:value-of select="text()" />. W zamian należy przejść po wszystkich węzłach potomnych i wybrać tylko właściwe (tekstowe) węzły. W przypadku bardziej zaawansowanego przetwarzania napis trzeba najpierw zapisać do zmiennej.

Dodatkowym problemem jest walidacja, która w praktyce jest bardzo trudna jeśli nie niemożliwa.

Czasem zachodzi potrzeba sprawdzenia czy wynikiem wyrażenia jest liczba. Jednym ze sposobów jest zastosowanie następującego porównania:

number(expr) = expr

W jaki sposób to działa ? Jeśli expr jest nie jest liczbą to wynikiem wyrażeniem number(expr) jest NaN. Wynikiem porównania NaN z dowolnym wyrażeniem jest false(). Jeśli natomiast expr jest liczbą to number(expr) też jest liczbą i wynikiem porównania jest true().

Podczas transformacji dokumentu XML za pomocą arkusza XSLT często zachodzi potrzeba wykonania akcji w zależności od spełnienia pewnych warunków. Język XSLT udostępnia konstrukcje xsl:if oraz xsl:choose pozwalające na warunkowe wykonanie fragmentów kodu. Zdarzają się jednak sytuacje kiedy do dyspozycji jest tylko jedno wyrażenie XPath, w którym należy zawrzeć instrukcję warunkową. Co wtedy ? Okazuje się, że można osiągnąć warunkowe wyrażenia XPath za pomocą funkcji concat() oraz substring().

Przykład:
W węźle 'wiek' znajduje się wiek osoby. Należy wypisać czy osoba jest dzieckiem czy dorosłym zakładając, że dziećmi są osoby, które nie mają skończonych 18 lat.

Rozwiązanie:

concat(
            substring('Dorosły', 1 div (wiek >= 18)), 
            substring('Dziecko', 1 div (wiek < 18))
      ) 

Jak to działa ? Wyrażenie jest konkatenacją dwóch, łańcuchów znakowych. Aby osiągnąc cel, którym jest wyrażenie warunkowe jeden z łańcuchów - w zależności od warunku - musi być zawsze pusty. O tym czy łańcuch jest pusty czy nie decyduje w powyższym wyrażeniu funkcja substring(). Drugi argument tej funkcji określa od którego miejsca w łańcuchu znakowym należy zacząć "wycinanie".  Wyrażenia wiek >= 18 oraz wiek < 18 mogą przyjmować jedną z dwoch wartości - true() lub false().  Ostatecznie otrzymujemy więc, że "wycinanie" powinno się zacząć (w zależności od wartości węzła 'wiek') od 1/true() lub 1/false(). Operacja dzielenia (div) automatycznie skonwertuje wartości logiczne do liczb. Otrzymamy zatem 1/1 lub 1/0. O ile wynik operacji 1/1 jest oczywisty to operacja 1/0 wydaje się sprzeczna z zasadami matematyki. Krótkie sprawdzenie i okazuje się, że wynik dla tej operacji zwrócony przez XSLT to... Infinity! W ten sposób w zależności od warunku "wycinanie" łańcucha znakowego zaczynamy od 1 elementu (czyli początku) lub w nieskończoności - co zawsze zwraca pusty łańcuch znakowy.

Przykład przedstawiony powyżej ilustruje typową instrukcje <<if then else>>. W prosty sposób można ją rozszerzyć na instrukcje <<switch>>. Podstawową wadą przedstawionego rozwiązania jest brak czytelności i konieczność doboru wzajemnie wykluczających się warunków.

W języku XSL brak jest typowych, znanych z imperatywnych języków programowania pętli. Czasem jednak zdarza się, że są one niezbędne. Jednym ze sposobów implementacji pętli w XSL jest zastosowanie rekurencji. Poniżej znajduje się przykład pętli wypisującej kolejne liczby od 1 do 10.

...
   <xsl:call-template name="loop" />
...
 






<xsl:template name="loop">
   <xsl:with-param name="idx" select="1" />
 


   <xsl:if test="$idx &lt;= 10">
      <xsl:value-of select="$idx" />

      <xsl:call-template name="loop">
         <xsl:with-param name="idx" select="$idx + 1" />
      </xsl:call-template>
   </xsl:if>
</xsl:template>

Do sprawdzania istnienia węzła można zastosować funkcje boolean oraz not.
Wyrażenie:

boolean(XPath) 

zwróci wartość true() jeśli węzeł na, który wskazuje XPath istnieje lub false() jeśli węzeł nie istnieje.
Działanie funkcji not() jest odwrotne. Wyrażenie:

not(XPath) 

zwróci wartość false() jeśli węzeł na, który wskazuje XPath istnieje lub true() jeśli węzeł nie istnieje.

Przykład:

<?xml version="1.0"?>
<root>
   <node>test</node>
</root>

1) <xsl:value-of select="boolean(/root/node)" />
    <!-- wynik: true -->

2) <xsl:value-of select="not(/root/node)" />
    <!-- wynik: false -->

Funkcja system-property zwraca wartość własności systemowej, której nazwa przekazana jest jako argument wywołania funkcji. W xslt dostępne są następujące właściwości:
- xsl:version
- xsl:vendor
- xsl:vendor-url
Dodatkowo niektórzy producenci dodają swoje właściwości. Np w przypadku procesorów Microsoftu dostępna jest własność o nazwie msxsl:version (zdefiniowana w przestrzeni nazw 'urn:schemas-microsoft-com:xslt').

Przykładowy arkusz XSLT:

<?xml version="1.0" encoding="ISO-8859-1"?>


<xsl:stylesheet version="1.0" 
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
 xmlns:msxsl="urn:schemas-microsoft-com:xslt">
  <xsl:template match="/">
   Version: <xsl:value-of 
     select="system-property('xsl:version')" /><br />
   Vendor: <xsl:value-of 
     select="system-property('xsl:vendor')" /><br />
   Vendor URL: <xsl:value-of 
     select="system-property('xsl:vendor-url')" /><br />
   msxsl version: <xsl:value-of 
     select="system-property('msxsl:version')" /><br />
  </xsl:template>
</xsl:stylesheet>

i wynik jego działania:

Version: 1
Vendor: Microsoft
Vendor URL: http://www.microsoft.com
msxsl version: 3

Jeśli w Internet Explorerze podamy URLa do dokumentu Xmlowego, w którym nie jest określony arkusz XSLT jaki ma zostać użyty do wygenerowania wyniku, Internet Explorer użyje swojego domyśnego arkusza. Do arkusza tego można się dostać podając w Internet Explorerze link res://msxml3.dll/DEFAULTSS.xsl lub res://msxml.dll/DEFAULTSS.xsl. res:// w linku oznacza, że arkusz jest zasobem w pliku dll.
UWAGA: Uważni na pewno zauważyli, że arkusz nie jest zgodny ze specyfikacją XSLT 1.0. Tak naprawdę dopiero MSXML 3.0 jest w pełni zgodny ze specyfikacją XSLT 1.0. Arkusz używany przez Internet Explorera wykorzystuje wczesną wersję roboczą specyfikacji XSLT znaną pod nazwą WD-xsl.

Czasami zachodzi potrzeba wyszukania lub podmienienia znaku apostrofa lub znaku cudzysłowia. Może to być kłopotliwe gdy jeden z tych znaków jest argumentem funkcji XPath. Jak sobie radzić w takich przypadkach ? Ponizej przykład wywołania funkcji translate usuwającej znaki apostrofu z bieżącego węzła:

<xsl:value-of select=
"translate(., &quot;&apos;&quot;, '')" />

Załóżmy, że w arkuszu XSLT zdefiniowana jest zmienna zawierająca węzeł a zadaniem jest sprawdzić czy ów węzeł należy do jakiegoś (zadanego) node-setu. Istnieją co namniej dwa rozwiązania tego problemu:

a) przy użyciu funkcji generate-id()
Wyrażenie XPath wygląda wtedy tak:

/root/node[generate-id(.)=generate-id($node)]

i sprawdza czy w zadanym node-secie istnieje węzeł mający takie samo id jak węzeł w zmiennej. Jeśli tak to znaczy, że musi to być węzeł ze zmiennej.

b) za pomocą operatora | (suma node-setów)
W tym przypadku porównujemy liczbe węzłów w zadanym node-secie z liczbą węzłów node-setu będącego sumą wyjściowego node-setu i węzła ze zmiennej. Te wartości będą równe tylko wtedy gdy wyjściowy node-set już zawierał węzeł ze zmiennej. Wyrażenie XPath wygląda następująco:

count(/root/node)=count(/root/node | $node)

XSLT (w szczególności wersja 1.0) nie jest za bardzo przyjazny formatowaniu tekstu. Czasem jednak wynik transformacji musi być sformatowany w dokładnie określony sposób. W takich przypadkach wstawienie znaku nowej linii może być problematyczne. Poniżej trzy proste sposoby pokazujące jak sobie z tym poradzić:

1) 
abc<xsl:text>&#xA;</xsl:text>def

2)
abc<xsl:text>
</xsl:text>def

3)
abc<![CDATA[
]]>def

Specyfikacja XML określa dokładnie jak powinny wyglądać nazwy węzłów w poprawnych dokumentach Xmlowych (http://www.w3.org/TR/xml/#NT-Name). Bywa jednak, że istnieje konieczność zastosowania nazwy niezgodnej ze specyfikacją (zazwyczaj przy automatycznym generowaniu dokumentów Xml na podstawie innego formatu lub głupi KaOwiec patrzy w kod i to nie tylko w damskiej ubikacji...). Wynikiem operacji jest wówczas niepoprawny dokument Xml, którego parsowanie zakończy się (lub przynajmniej powinno zakończyć się) błędem. Istnieje możliwość uniknięcia tego problemu - na platformie .NET dostępna jest klasa XmlConvert, która potrafi z nazwy niezgodnej ze specyfikacją zrobić nazwę, która nie będzie powodować problemów podczas parsowania dokumentu Xml. Oczywiście klasa udostępnia także funkcje działające w drugą stronę - zwracające oryginalną nazwę wcześniej zakodowanego elementu. Kilka przykładów konwersji (funkcja EncodeName):

[ID]            -> _x005B_ID_x005D_
3d-logic        -> _x0033_d-logic
Data zamówienia -> Data_x0020_zamówienia
Order#          -> Order_x0023_

Jeśli nazwa przekazana do konwersji okaże się poprawna to funkcja kodująca nazwy zwróci string podany na wejście - np.:

_3d-logic -> _3d-logic

Klasa XmlConvert posiada jeszcze kilka innych ciekawych metod (np. VerifyName sprawdzającą czy podany string jest poprawną nazwą według specyfikacji). Pełny opis klasy znajduje się tutaj.

Zamiana XDocument (Linq to Xml) na XmlDocument (DOM) wygląda następująco:

XmlDocument xmlDoc = new XmlDocument();
xmlDoc.Load(xdoc.CreateReader());

Zamianę w drugą stronę (tzn. XmlDocument na XDocument)  robi się tak:

XDocument xDoc = XDocument.Load(new XmlNodeReader(xmlDoc));

Instrukcja xsl:output pozwala na zdefiniowanie formatu dokumentu wynikowego transformacji. Jednak gdy wynik transformacji jest serializowany za pomocą obiektu typu XmlWriter może okazać się, że powstały dokument nie jest sformatowany zgodnie z oczekiwaniami. Na pierwszy rzut oka wygląda to na bug w .NET Frameworku jednak... jest to celowe ("this is not a bug, this is a feature"). Otóż specyfikacja Xslt stara sie rozdzielić transformację, której wynikiem jest drzewo, od serializacji tego drzewa. Klasy XslCompiledTransform i XmlWriter są odzwierciedleniem tej koncepcji - XslCompiledTransform jest odpowiedzialny za transformację podczas gdy XmlWriter za serializację. Dodatkową zaletą powyższej architektury jest umożliwienie serializacji drzewa wynikowego dostoswanej do specyficznych potrzeb użytkownika. Wystarczy stworzyć własną klasę dziedziczącą z klasy XmlWriter i przekazać ją jako parametr transformacji. Niestety rozdzielenie transformacji od serializacji stwarza pewien problem. W transfosormacji można definiować pewne aspekty serializacji (instrukcja xsl:output!), ale ponieważ sama serializacja to "całkiem inna bajka" nie mogą one być przekazane do procesu serializacji automatycznie. Odpowiedzialność za przekazanie tych informacji spoczywa na programiście. Jest to dość proste -  klasa XslCompiledTransform posiada właściwość OuputSettings (obiekt XmlWriterSettings, tylko do odczytu) zawierającą infromacje wyspecyfikowane w instrukcji xsl:output przetwarzanego arkusza Xslt. Należy je przekazać do writera. Najprościej to zrobić w następujący sposób:

XslCompiledTransform xslt = new XslCompiledTransform();
xslt.Load("arkusz.xslt");
XmlWriter result = XmlWriter.Create(Console.Out, 
			xslt.OutputSettings);
xslt.Transform("test.xml", result)

Odrębny obiekt zawierający informacje o serializacji przekazywany do writera otwiera dodatkowe możliwości. Można na przykład formatować dokumenty wyjściowe zawsze w ten sam sposób, niezależnie od formatu zdefiniowanego w instrukcji xsl:output. Innym, nieco ciekawszym przypadkiem, jest modyfikacja tylko niektórych właściwości. Taka operacja wymaga najpierw sklonowania obiektu XmlWriterSettings, jak w przykładzie poniżej:

XslCompiledTransform xslt = new XslCompiledTransform();
xslt.Load("arkusz.xslt");
XmlWriterSettings ws = xslt.OutputSettings.Clone();
ws.Indent = true;
XmlWriter result = XmlWriter.Create(Console.Out, ws);
xslt.Transform("test.xml", result);

Tworzenie atrybutów w dokumencie Xslt jest proste - albo używamy instrukcji xsl:attribute której atrybut name określa nazwę tworzonego atrybutu a ciało - zawartość, albo - co jest chyba jeszcze bardziej naturalne - w tworzonym elemencie wpisujemy atrybut tak jak ma on wygladac w dokumencie wyjściowym. W drugim przypadku możemy użyć nawiasów klamrowych żeby wstawić wartość ze źródłowego dokumentu (jest to tzw. AVT czyli Attribute Value Template). To właśnie te nawiasy klamrowe mogą sprawić troszkę kłopotu - chyba głównie dlatego, że tak naprawdę dość rzadko istnieje konieczność wstawienia nawiasu klamrowego W wartości atrybutu. Generalnie dwa główne przypadki to chyba JavaScript (np. atrybut onClick zawierający instrukcję warunkową) oraz WPF/XAML.

Załóżmy, że nasz Xslt ma za zadanie "wyprodukować" następujący element w dokumencie wynikowym:

<Button Name="btn2" IsEnabled="{Binding ElementName=btn1,
Converter={StaticResource BooleanToVisibility}}" />

Po skopiowaniu powyższej linijki do arkusza Xslt procesor zgłosi błąd, którego źródłem są nawiasy klamrowe (procesor Xslt traktuje wyrażenie w nawiasach jako AVT). Chwila namysłu... i mamy "obejście" problemu:

<Button Name="btn2">
      <xsl:attribute name="IsEnabled">{Binding ElementName=btn1,
Converter={StaticResource BooleanToVisibility}}</xsl:attribute>
</Button>

Nawet działa... Tylko nie jest za bardzo naturalne. Przede wszystkim znamy nazwę atrybutu - nie ma więc powodu żeby używać instrukcji xsl:attribute. Tym bardziej, że wartość atrybutu też jest znana. Na szczęście twórcy Xslt przewidzieli ten problem. Wystarczy znak '{' zastąpić sekwencją '{{' a znak '}' zastąpić sekwencją '}}' i wszystko działa jak należy. Ostatecznym rozwiązaniem jest więc:

<Button Name="btn2" IsEnabled="{{Binding ElementName=btn1,
Converter={{StaticResource BooleanToVisibility}}}}" />