Staffan Malmgrens blogg

Tidigare frågade jag runt vilket som var det bästa sättet att skapa PDF från nån typ av strukturerad XML-data. De svar jag fick från olika håll pekade på att köra det gen om en CSS3-kapabel layoutmotor vore lämpligt. Så jag har ägnat lite tid åt att trimma in ett stylesheet anpassat för lagtext uttryckt XHTML2 tillsammans med metadata från ESFR-vokabulären.

Som testobjekt använde jag den lagtext som utgör kursfordran för förvaltningsrätt, dvs den kurs jag läser för närvarande. Tidigare har ett förlag tryckt upp en särskild författningssamling för detta ämne, men på introduktionsföreläsningen nämndes att detta inte skulle göras i år, då kostnaden för att ta fram uppdaterade tryckorginal för varje kursstart var för stor (kursen går två gånger om året).

Nu har jag ett automatiserat publiceringsflöde, som utgående från en huvudfil, uttryckt i XHTML2, och en samling lagtexter, också uttryckt i XHTML2, genererar en sammmanslagen fil. Denna innehåller alla författningar (eller delar därav) som huvudfilen hänvisar till genom XInclude/XPointer. Från den sammanslagna filen och ett CSS3-stylesheet skapas sen en PDF. Första steget görs med xmllint –xinclude, andra med Prince. Kostnad för att ta fram uppdaterade tryckoriginal: i princip noll.

Resultat: enkelspaltig (css), dubbelspaltig (css).

Några saker att lägga märke till:

• Innehållsförteckningen har korrekta sidnummerhänvisningar
• Sidhuvudet visar var och i vilken lag man befinner sig på (och växlar utseende beroende på om det är en kapitelindelad lag eller inte)
• Huvudfilen anger vilka förkortningar som ska användas för aktuell lag i sidhuvudet
• Höger- och vänstersidor ser olika ut (precis som i riktiga böcker!)
• Avstavning sker automatiskt efter svenska regler
• PDF-bokmärkena ger en hierarkisk översikt över hela filen
• Det går att inkludera bara enstaka kapitel (eller andra avsnitt) från en lag

Det finns förstås mycket kvar att fixa (kolla exv SekrL 16 kap - inte många rätt i formatteringen där), och även mer att skriva om hur man kan använda CSS3 och Prince XML, men det får bli efter julen.

Det borde inte vara så svårt att modellera lagtext efter ett etablerat schema för textinformation, kan man tycka. Låt gå att HTML4 inte är världens mest sofistikerade modell, men den har rubriker, stycken och listor - det har ju lagtext också. På den nivån borde semantiken stämma överrens, eller?

Nej, naturligtvis inte, för då skulle jag ju inte sitta och skriva det här. Ett exempel är att HTML4 (och därmed XHTML1) inte har någon strukturmekanism som matchar de olika nivåerna som finns i lagtext (avdelningar, kapitel, paragrafer) — det enda som finns är stycken samt och den ganska intetsägande grupperingskonstruktionen <div>.

Ett annat är att i HTML-modellen är en lista (numrerad eller onumrerad) något som befinner sig utanför ett stycke. Det är helt enkelt inte tillåtet att ha en lista i ett stycke. Men enligt modellen/kutymen som används i svensk lagtext så hör en lista till närmast föregående stycke — ska man exempelvis hänvisa till den text i upphovsrättslagen som lyder “skönlitterär eller beskrivande framställning i skrift eller tal” säger man “1 § 1 st 1 p” (observera att man inte säger “1 kap. 1 § 1 st 1 p.” — kapitelhänvisningen utelämnas när paragrafnumreringen räcker för att unikt identifiera en given paragraf, vilket det gör i upphovsrättslagen)

XHTML2 löser de här problemen. Man kan ange att delar av texten logiskt sett är delar av ett större sammanhang genom <section>-taggen (som dessutom ger effekt på rubriker, så att man kan använda <h>-taggen genomgående utan att behöva fippla med h1, h2, h3 osv.

Den tillåter även att en lista (numrerad eller onumrerad) är en del av ett stycke.

Men det finns fortfarande ytterligare minst ett förekommande mönster i svensk lagtext som XHTML2 inte kan efterlikna, nämligen ovanan att stoppa in nya element i en numrerad lista. Ta exempelvis Mervärdesskattelagen, 5 kap. 9 § och den lista som finns där - nånstans under lagens levnad bestämde lagstiftaren att stoppa något nytt mellan punkt 4 och 5 – resultatet blev punkt 4 a. Visst känns det lite som att lagstiftaren programmerat BASIC på 1980-talets hemdatorer? Man får vara glad att det inte finns någon juridisk RENUM.

Det här kan XHTML2 inte efterlikna, eftersom dess modell kräver att alla element i en numrerad lista ska ha ett nummer som faktiskt är ett nummer och inte en friformsetikett.

För att överkomma den här modellimpedansmismatchen får jag helt enkelt modellera numrerade listor i lagtexter som onumrerade listor, och låta numreringen utgöra en del av varje punkts PCDATA-text (samt uttrycka samma information som del av ett xml:id-attribut).

Samma mönster att stoppa in nya element förekommer för övrigt på andra ställen i lagstiftningen, såsom paragraf- och kapitelnivå — se exv 11 a § och 2 a kap. i upphovsrättslagen. Det här är dock inget egentligt problem för XHTML2-modellering, eftersom det här inte finns något alternativ till att låta dessa elements numrering uttryckas på annat sätt än som en del av dess PCDATA. Det är bara det att just för listor så finns potentialen att göra Rätt, men på grund av en restriktiv XHTML2-modell, alternativt en slarvig lagstiftare, är det ändå inte möjligt.

Värst är det när nya stycken stoppas in — eftersom dessa inte numreras explicit blir en hänvisning till “4 § 3 st” trasig när lagstiftaren bestämmer sig för att stoppa in ett nytt stycke mellan första och andra stycket i den paragrafen.