Weblog Tomasza Przechlewskiego

Ćwiczenie z XSLT

Zadanie polega na wydłubaniu z pliku GPX pierwszego i ostatniego elementu <time>, który jest dzieckiem elementu <trkpt>. (Nie może być po prostu <time>, bo element ten występuje także w innym kontekście.)

Coś takiego wymyśliłem:

<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:gpx="http://www.topografix.com/GPX/1/0">

<xsl:output method="text"/>

<xsl:param name='Position' select="'First'"/> 

<xsl:template match="/" >

<xsl:for-each select='//gpx:trkpt'> 

  <xsl:if test="position()=1 and $Position='First'">
    <xsl:value-of select='gpx:time'/>
    <xsl:text>&#10;</xsl:text>
  </xsl:if>

  <xsl:if test="position()=last() and $Position='Last'">
    <xsl:value-of select='gpx:time'/>
    <xsl:text>&#10;</xsl:text>
  </xsl:if>
  
</xsl:for-each>
  
</xsl:template>

</xsl:stylesheet>

W praniu się okazało, że jest jeden drobny, komplikujący życie feler-nie-feler. Struktura plików GPX (w zależności od tego czym są one generowane) jest identyfikowana albo z przestrzenią nazw http://www.topografix.com/GPX/1/0 albo z http://www.topografix.com/GPX/1/1. Praktycznie żadna różnica, ale szablon przestaje działać. Aby uodpornić szablon na wersje formatu można zamienić:

<xsl:for-each select='//gpx:trkpt'>

<xsl:for-each select='//*[local-name()="trkpt"]'>

Teraz szablon `reaguje' na element <trkpt> z dowolnej przestrzeni nazw. Oczywiście reguła wyboru węzłów stała się teraz `mniej specyficzna', co w przypadku bardziej skomplikowanych transformacji może nie być najlepszym pomysłem, ale w przypadku tak prostego schematu jak GPX i banalnej transformacji, jak powyższa nie powinno być problemów.

Podobnie można zamienić:

<xsl:value-of select='gpx:time'/>

na:

<xsl:value-of select='*[local-name()="time"]'/>

Teraz, przykładowo uruchomienie xsltproc (opisany wyżej szablon jest zawartością pliku gpxtimestamp.xsl):

xsltproc --param Position '"First"' gpxtimestamp.xsl 20120107.xml
xsltproc --param Position '"Last"' gpxtimestamp.xsl 20120107.xml

Wypisuje odpowiednio zawartość pierwszego i ostatniego elementu <time>.

url | Sun, 08/01/2012 21:53 | tagi: xml, xslt

Zbędne deklaracje xmlns przy zamianie KML→GPX

Z pliku XML w wersji KML, tj. googleearth chcę wydłubać współrzędne punktów MyPlaces oraz zapisać je w formacie GPX (celem późniejszego załadowania do Garmina). Używam do tego następującego arkusza XSLT:

]]>

Gdyby w powyższym arkuszu XSLT zamiast

    <wpt xsl:exclude-result-prefixes="gpx kml" 
         xmlns='http://www.topografix.com/GPX/1/0'>
    ...

było po prostu:

    <wpt xsl:exclude-result-prefixes="gpx kml" 
    ...

to znaczy zostałaby pominięta deklaracja przestrzeni nazw elementu wpt, wtedy procesor XSLT zapisałby na wyjściu coś w rodzaju:

 <wpt xmlns="" lat="19.35304208110762" lon="54.35681836243874">
   ...

A to oznacza, że wpt pochodziłby z pustej przestrzeni nazw, xmlns="". Niby proste, ale nie jest oczywiste jak usunąć -- na pierwszy rzut oka zbędne (a tak na prawdę błędne) -- wpisy xmlns="".

url | Wed, 31/03/2010 09:21 | tagi: gpx, inne, kml, xslt

Drobny przykład w XSLT

Fragment pliku XML wygląda jakoś tak:

 <month no="1">  
   <item data="2009/01/03" dist="20" exdist="18.60" />
   <item data="2009/01/25" dist="50" exdist="49.10" />
 <month no="2">  
   ...
 </month>

Wszystkie item pomiędzy month trzeba zsumować aż do zadanego numeru miesiąca (włącznie), który jest n.b. wartością atrybutu no. Poniższy szablon wykona ww. zadanie:

  <xsl:template name='drukuj-do-mc'>
    <xsl:param name='mc'/>
    <xsl:text> [od początku roku: </xsl:text>
    <xsl:value-of select="sum(//item[not(../@no &gt; $mc)]/@dist)"/>
    <xsl:text> km] </xsl:text>
  </xsl:template>

Wyróżniony wiersz zawiera kluczowe przekształcenie XPath: //item[not(../@no > $mc)]/@dist, co można zinterpretować następująco: wszystkie atrybuty dist przyczepione do elementu item, z całego dokumentu, ale pod warunkiem, że wartość atrybutu no elementu nadrzędnego jest nie większa niż $mc.

url | Fri, 22/05/2009 17:57 | tagi: xml, xslt

Formatowanie elementu optional (w Docbook XML)

W nazwiązaniu do poprzedniego wpisu. W dokumencie o XPath pojawia się taki oto fragment:

[predykat]*]]>

Co ma oznaczać, że wyrażenie ścieżkowe XPath składa się z osi i testu oraz opcjonalnego predykatu, który może być powtórzony wielokrotnie (stąd *). Teraz standardowo szablony XSL Docbook (aka XSLDB) zamieniają ww. fragment XML na coś takiego:

oś::test[[predykat]*]

Niezręczność polega na tym, że nawiasy kwadratowe raz są używane do oznaczania części opcjonalnej a raz oznaczają, że należy je wstawić literalnie. W XSLDB znaki wstawiane wokół elementu optional są sparametryzowane -- są to mianowicie: arg.choice.opt.open.str oraz arg.choice.opt.close.str. Zamiast `[' i `]' zdecydowałem się na U+27E8 (Mathematical left angle bracket) oraz U+27E9 (Mathematical right angle bracket) Teraz próba uruchomienia:

xsltproc --stringparam arg.choice.opt.open.str "&#x27e8;" \
   --stringparam arg.choice.opt.close.str" select="&#x27e9;" ...

Kończy się błędem basha... Ciekawe czemu? Można podać ww. znaki binarnie -- wtedy wszystko działa. Ale UTF-8 w Makefile? Miałem opory, dodałem więc do arkusza uruchamiającego transformację XML → XHTML:

<xsl:param name="arg.choice.opt.open.str" select="'&#x27e8;'" />
<xsl:param name="arg.choice.opt.close.str" select="'&#x27e9;'" />

Teraz omawiany fragment wygląda mniej dwuznacznie:

oś::test⟨[predykat]*⟩

BTW w trybie nxml wpisanie ⟨ powoduje, że automagicznie kształt znaku pojawia się za średnikiem (ale nie jest wstawiany do tekstu -- po prostu jest to podpowiedź Emacsa, jak wygląda kształt znaku.) Dodatkowo po najechaniu myszą na encję wyświetlana jest nazwa znaku (w oknie podpowiedzi zwanym tooltip). Te ułatwienia są fajne w środowisku jednobajtowym--a ja póki co używam jako domyślnego kodowania ISO-8859-2.

Przy okazji użyteczne zestawienie znaków Unicode -- odpowiedników różnych TeXowych symboli matematycznych. Wystarczy zaznaczyć myszą i wkleić do Emacsa a następnie C-x = (what-cursor-position) wyświetli co zacz, w tym numer znaku.

url | Sat, 01/11/2008 20:58 | tagi: docbook, emacs, utf8, xml, xslt

SVG, Docbook i Firefox

Zaczęło się od tego, że chciałem wstawić ilustrację w formacie SVG do dokumentu redagowanego w Docbooku. Jakoś tak:


  Osie (środkowy węzeł <literal>p</literal> jest węzłem kontekstowym)
  
    
      
    
  
]]>

W pliku PDF wygenerowanym FOPem ilustracja wygląda OK. W dokumencie HTML oglądanym w FF 2.0.0.16 wygląda dziwnie: wyświetlany jest tylko fragment rysunku a z boku pojawia się pasek do przewijania (scrollbar). I nie idzie tego się pozbyć...

Zaktualizowałem zatem Firefoxa do wersji 3.0.3. Teraz rysunek jest wyświetlany prawidłowo. Opera 9.27 nie pokazuje go wcale, ale jeżeli pominie się atrybut width, to rysunek jest wyświetlany prawidłowo. Skoro tak to wymyśliłem sobie coś takiego:


  Osie (środkowy węzeł <literal>p</literal> jest węzłem kontekstowym)
  
    
      
    
    Na wypadek gdyby powyższy rysunek
był niewidoczny tu jest wersja w formacie PNG 
    
  
]]>

Powyższa uwaga w pliku PDF jest bez sensu. Na szczęście łatwo się go pozbyć, bo w Docbooku zaimplementowano warunkowe przetwarzanie dokumentu (profiling). Następujące kilkanaście atrybutów może być używanych do tego celu:

Nazwa atrybutu	Opis	Parameter XSL
arch	Computer or chip architecture, such as i386.	profile.arch
audience	Intended audience of the content, such as instructor.	profile.audience
condition	General purpose conditional attribute, with no preassigned semantics.	profile.condition
conformance	Standards conformance, such as lsb (Linux Standards Base).	profile.conformance
lang	Language code, such as de_DE.	profile.lang
os	Operating system.	profile.os
revision	Editorial revision, such as v2.1.	profile.revision
revisionflag	Revision status of the element, such as changed. This attribute has a fixed set of values to choose from.	profile.revisionflag
role	General purpose attribute, with no preassigned semantics. Use with caution for profiling.	profile.role
security	Security level, such as high.	profile.security
status	Editorial or publication status, such as InDevelopment or draft.	profile.status
userlevel	Level of user experience, such as beginner.	profile.userlevel
vendor	Product vendor, such as apache.	profile.vendor
wordsize	Word size (width in bits) of the computer architecture, such as 64bit. Added in DocBook version 4.4.	profile.wordsize

Teraz po wpisaniu ... ]]> do dokumentu należy uruchomić procesor XSLT z odpowiednią wartością parametru (podanego w trzeciej kolumnie tabeli). Mówiąc konkretnie:

## Transformacja za pomocą xsltproc xml2xhtml
xsltproc --stringparam chunker.output.doctype-public "-//W3C//DTD XHTML 1.0 Strict//EN" \
     --stringparam chunker.output.doctype-system http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" \
     --stringparam profile.condition "html" -o plik.xhtml szablon.xsl plik.xml

## albo za pomocą procesora saxon:
saxon -o plik.fo plik.xml szablon.xsl profile.condition="pdf"

Do tego zamiast standardowego arkusza XSL-ROOT/xhtml/chunk.xsl (XSL-ROOT oznacza katalog główny dystrybucji arkuszy XSL Docbook) należy w przypadku zamiany na XHTML uruchomić XSL-ROOT/xhtml/profile-chunk.xsl. Podobnie zamieniając XML na FO/PDF należy uruchomić XSL-ROOT/fo/profile-docbook.xsl zamiast XSL-ROOT/fo/docbook.xsl. Oczywiście ww. arkusze są uruchamiane pośrednio, poprzez arkusz dopasowujący nastawy XSL Docbook do moich potrzeb. Początek tego arkusza wygląda zatem następująco:

]]>

Teraz jest tak: plik PDF jest OK. Plik XHTML nie do końca--nie widać wpisu Na wypadek gdyby powyższy rysunek.... Zasłania go rysunek; co ciekawe identycznie wygląda to w Firefoksie i Operze (tzn. identycznie nic nie widać). Relewantny fragment pliku XHTML wygląda następująco:

Rysunek 1. Osie (środkowy węzeł p jest węzłem kontekstowym)