1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>The XSLT C library for Gnome</title>
<meta name="GENERATOR" content="amaya V5.0">
<meta http-equiv="Content-Type" content="text/html">
</head>
<body bgcolor="#ffffff">
<h1 align="center">The XSLT C library for Gnome</h1>
<h1 style="text-align: center">libxslt</h1>
<p>Libxslt is the <a href="http://www.w3.org/TR/xslt">XSLT</a> C library
developped for the Gnome project. XSLT itself is a an XML language to define
transformation for XML. Libxslt is based on <a
href="http://xmlsoft.org/">libxml2</a> the XML C library developped for the
Gnome project. It also implements most of the EXSLT set of extensions
functions and some of Saxon's evaluate and expressions extensions.</p>
<p>People can either embed the library in their application or use xsltproc
the command line processing tool. This library is free software and can be
reused in commercial applications (see the <a href="intro.html">intro</a>)</p>
<p>External documents:</p>
<ul>
<li>John Fleck wrote <a href="tutorial/libxslttutorial.html">a tutorial for
libxslt</a></li>
<li><a href="xsltproc.html">xsltproc user manual</a></li>
<li><a href="http://xmlsoft.org/">the libxml documentation</a></li>
</ul>
<p></p>
<h2><a name="Introducti">Introduction</a></h2>
<p>This document describes <a href="http://xmlsoft.org/XSLT/">libxslt</a>,
the <a href="http://www.w3.org/TR/xslt">XSLT</a> C library developed for the
<a href="http://www.gnome.org/">Gnome</a> project.</p>
<p>Here are some key points about libxslt:</p>
<ul>
<li>Libxslt is a C implementation</li>
<li>Libxslt is based on libxml for XML parsing, tree manipulation and XPath
support</li>
<li>It is written in plain C, making as few assumptions as possible, and
sticking closely to ANSI C/POSIX for easy embedding. Should works on
Linux/Unix/Windows.</li>
<li>This library is released under the <a
href="http://www.gnu.org/copyleft/lesser.html">GNU LGPL</a> and a
derivative of the W3C IPR (check the Copyright and the IPR files in the
distribution). If you are not happy with this, drop me a mail.</li>
<li>Though not designed primarily with performances in mind, libxslt seems
to be a relatively fast processor.</li>
</ul>
<h2><a name="Documentat">Documentation</a></h2>
<p>There are some on-line resources about using libxslt:</p>
<ol>
<li>Check the <a href="html/libxslt-lib.html#LIBXSLT-LIB">API
documentation</a> automatically extracted from code comments (using <a
href="http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=gtk-doc">gtk
doc</a>).</li>
<li>Look at the <a href="http://mail.gnome.org/archives/xslt/">mailing-list
archive</a>.</li>
<li>Of course since libxslt is based on libxml, it's a good idea to at
least read <a href="http://xmlsoft.org/">libxml description</a></li>
</ol>
<h2><a name="Reporting">Reporting bugs and getting help</a></h2>
<p>Well, bugs or missing features are always possible, and I will make a
point of fixing them in a timely fashion. The best way to report a bug is to
use the <a href="http://bugzilla.gnome.org/buglist.cgi?product=libxslt">Gnome
bug tracking database</a> (make sure to use the "libxslt" module name). I
look at reports there regularly and it's good to have a reminder when a bug
is still open. Be sure to specify that the bug is for the package libxslt.</p>
<p>There is also a mailing-list <a
href="mailto:xslt@gnome.org">xslt@gnome.org</a> for libxslt, with an <a
href="http://mail.gnome.org/archives/xslt/">on-line archive</a>. To subscribe
to this list, please visit the <a
href="http://mail.gnome.org/mailman/listinfo/xslt">associated Web</a> page
and follow the instructions.</p>
<p>Alternatively, you can just send the bug to the <a
href="mailto:xslt@gnome.org">xslt@gnome.org</a> list, if it's really libxslt
related I will approve it.. Please do not send me mail directly especially
for portability problem, it makes things really harder to track and in some
cases I'm not the best person to answer a given question, ask the list
instead. <strong>Do not send code, I won't debug it</strong> (but patches are
really appreciated!).</p>
<p>If you need help with the XSLT language itself, I strongly suggest to
subscribe to <a href="http://www.mulberrytech.com/xsl/xsl-list">XSL-list</a>,
check <a href="http://www.biglist.com/lists/xsl-list/archives/">the XSL-list
archives</a>, the <a href="http://www.dpawson.co.uk/xsl/xslfaq.html">XSL
FAQ</a>. The <a
href="http://www.nwalsh.com/docs/tutorials/xsl/xsl/slides.html">tutorial</a>
written by Paul Grosso and Norman Walsh is a very good on-line introdution to
the language. And I suggest to buy Michael Kay "XSLT Programmer's Reference"
book published by <a href="http://www.wrox.com/">Wrox</a> if you plan to work
seriously with XSLT in the future.</p>
<p>Check the following too before posting:</p>
<ul>
<li>make sure you are <a href="ftp://xmlsoft.org/">using a recent
version</a>, and that the problem still shows up in those</li>
<li>check the <a href="http://mail.gnome.org/archives/xslt/">list
archives</a> to see if the problem was reported already, in this case
there is probably a fix available, similarly check the <a
href="http://bugzilla.gnome.org/buglist.cgi?product=libxslt">registered
open bugs</a></li>
<li>make sure you can reproduce the bug with xsltproc, a very useful thing
to do is run the transformation with -v argument and redirect the
standard error to a file, then search in this file for the transformation
logs just preceding the possible problem</li>
<li>Please send the command showing the error as well as the input and
stylesheet (as an attachment)</li>
</ul>
<p>Of course, bugs reports with a suggested patch for fixing them will
probably be processed faster.</p>
<p>If you're looking for help, a quick look at <a
href="http://mail.gnome.org/archives/xslt/">the list archive</a> may actually
provide the answer, I usually send source samples when answering libxslt
usage questions. The <a
href="html/libxslt-lib.html#LIBXSLT-LIB">auto-generated documentation</a> is
not as polished as I would like (I need to learn more about Docbook), but
it's a good starting point.</p>
<h2><a name="help">How to help</a></h2>
<p>You can help the project in various ways, the best thing to do first is to
subscribe to the mailing-list as explained before, check the <a
href="http://mail.gnome.org/archives/xslt/">archives </a>and the <a
href="http://bugzilla.gnome.org/buglist.cgi?product=libxslt">Gnome bug
database:</a>:</p>
<ol>
<li>provide patches when you find problems</li>
<li>provide the diffs when you port libxslt to a new platform. They may not
be integrated in all cases but help pinpointing portability problems
and</li>
<li>provide documentation fixes (either as patches to the code comments or
as HTML diffs).</li>
<li>provide new documentations pieces (translations, examples, etc ...)</li>
<li>Check the TODO file and try to close one of the items</li>
<li>take one of the points raised in the archive or the bug database and
provide a fix. <a href="mailto:daniel@veillard.com">Get in touch with me
</a>before to avoid synchronization problems and check that the suggested
fix will fit in nicely :-)</li>
</ol>
<h2><a name="Downloads">Downloads</a></h2>
<p>The latest versions of libxslt can be found on <a
href="ftp://xmlsoft.org/">xmlsoft.org</a> (<a
href="ftp://speakeasy.rpmfind.net/pub/libxml/">Seattle</a>, <a
href="ftp://fr.rpmfind.net/pub/libxml/">France</a>) or on the <a
href="ftp://ftp.gnome.org/pub/GNOME/MIRRORS.html">Gnome FTP server</a> either
as a <a href="ftp://ftp.gnome.org/pub/GNOME/stable/sources/libxslt/">source
archive</a> or <a
href="ftp://ftp.gnome.org/pub/GNOME/contrib/redhat/SRPMS/">RPM packages</a>.
(NOTE that you need the <a
href="http://rpmfind.net/linux/RPM/libxml2.html">libxml2</a>, <a
href="http://rpmfind.net/linux/RPM/libxml2-devel.html">libxml2-devel</a>, <a
href="http://rpmfind.net/linux/RPM/libxslt.html">libxslt</a> and <a
href="http://rpmfind.net/linux/RPM/libxslt-devel.html">libxslt-devel</a>
packages installed to compile applications using libxslt.) <a
href="mailto:izlatkovic@daenet.de">Igor Zlatkovic</a> is now the maintainer
of the Windows port, <a
href="http://www.fh-frankfurt.de/~igor/projects/libxml/index.html">he
provides binaries</a>. <a href="mailto:Gary.Pennington@sun.com">Gary
Pennington</a> provides <a
href="http://garypennington.net/libxml2/">Solaris binaries</a>.</p>
<p><a name="Contribs">Contribs:</a></p>
<p>I do accept external contributions, especially if compiling on another
platform, get in touch with me to upload the package. I will keep them in the
<a href="ftp://xmlsoft.org/contribs/">contrib directory</a></p>
<p>Libxslt is also available from CVS:</p>
<ul>
<li><p>The <a
href="http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=libxslt">Gnome
CVS base</a>. Check the <a
href="http://developer.gnome.org/tools/cvs.html">Gnome CVS Tools</a>
page; the CVS module is <b>libxslt</b>.</p>
</li>
<li><a
href="ftp://xmlsoft.org/XSLT/cvs-snapshot.tar.gzftp://xmlsoft.org/XSLT/cvs-snapshot.tar.gzftp://xmlsoft.org/XSLT/cvs-snapshot.tar.gz">daily
snapshots from CVS</a>
are also provided</li>
</ul>
<h2><a name="News">News</a></h2>
<h3>CVS only : check the <a
href="http://cvs.gnome.org/lxr/source/libxslt/ChangeLog">Changelog</a> file
for a really accurate description</h3>
<h3>1.0.8: Nov 26 2001</h3>
<ul>
<li>fixed an annoying header problem, removed a few bugs and some code
cleanup</li>
<li>patches for Windows and update of Windows Makefiles by Igor</li>
<li>OpenVMS port instructions from John A Fotheringham</li>
<li>fixed some Makefiles annoyance and libraries prelinking
informations</li>
</ul>
<h3>1.0.7: Nov 10 2001</h3>
<ul>
<li>remove a compilation problem with LIBXSLT_PUBLIC</li>
<li>Finishing the integration steps for Keith Isdale debugger</li>
<li>fixes the handling of indent="no" on HTML output</li>
<li>fixes on the configure script and RPM spec file</li>
</ul>
<h3>1.0.6: Oct 30 2001</h3>
<ul>
<li>bug fixes on number formatting (Thomas), date/time functions (Bruce
Miller)</li>
<li>update of the Windows Makefiles (Igor)</li>
<li>fixed DOCTYPE generation rules for HTML output (me)</li>
</ul>
<h3>1.0.5: Oct 10 2001</h3>
<ul>
<li>some portability fixes, including Windows makefile updates from
Igor</li>
<li>fixed a dozen bugs on XSLT and EXSLT (me and Thomas Broyer)</li>
<li>support for Saxon's evaluate and expressions extensions added (initial
contribution from Darren Graves)</li>
<li>better handling of XPath evaluation errors</li>
</ul>
<h3>1.0.4: Sep 12 2001</h3>
<ul>
<li>Documentation updates from John fleck</li>
<li>bug fixes (DocBook FO generation should be fixed) and portability
improvements</li>
<li>Thomas Broyer improved the existing EXSLT support and added String,
Time and Date core functions support</li>
</ul>
<h3>1.0.3: Aug 23 2001</h3>
<ul>
<li>XML Catalog support see the doc</li>
<li>New NaN/Infinity floating point code</li>
<li>A few bug fixes</li>
</ul>
<h3>1.0.2: Aug 15 2001</h3>
<ul>
<li>lot of bug fixes, increased the testsuite</li>
<li>a large chunk of EXSLT is implemented</li>
<li>improvements on the extension framework</li>
<li>documentation improvements</li>
<li>Windows MSC projects files should be up-to-date</li>
<li>handle attributes inherited from the DTD by default</li>
</ul>
<h3>1.0.1: July 24 2001</h3>
<ul>
<li>initial EXSLT framework</li>
<li>better error reporting</li>
<li>fixed the profiler on Windows</li>
<li>bug fixes</li>
</ul>
<h3>1.0.0: July 10 2001</h3>
<ul>
<li>a lot of cleanup, a lot of regression tests added or fixed</li>
<li>added a documentation for <a href="extensions.html">writing
extensions</a></li>
<li>fixed some variable evaluation problems (with William)</li>
<li>added profiling of stylesheet execution accessible as the xsltproc
--profile option</li>
<li>fixed element-available() and the implementation of the various
chunking methods present, Norm Walsh provided a lot of feedback</li>
<li>exclude-result-prefixes and namespaces output should now work as
expected</li>
<li>added support of embedded stylesheet as described in section 2.7 of the
spec</li>
</ul>
<h3>0.14.0: July 5 2001</h3>
<ul>
<li>lot of bug fixes, and code cleanup</li>
<li>completion of the little XSLT-1.0 features left unimplemented</li>
<li>Added and implemented the extension API suggested by Thomas Broyer</li>
<li>the Windows MSC environment should be complete</li>
<li>tested and optimized with a really large document (DocBook Definitive
Guide) libxml/libxslt should really be faster on serious workloads</li>
</ul>
<h3>0.13.0: June 26 2001</h3>
<ul>
<li>lots of cleanups</li>
<li>fixed a C++ compilation problem</li>
<li>couple of fixes to xsltSaveTo()</li>
<li>try to fix Docbook-xslt-1.4 and chunking, updated the regression test
with them</li>
<li>fixed pattern compilation and priorities problems</li>
<li>Patches for Windows and MSC project mostly contributed by Yon Derek</li>
<li>update to the Tutorial by John Fleck</li>
<li>William fixed bugs in templates and for-each functions</li>
<li>added a new interface xsltRunStylesheet() for a more flexible output
(incomplete), added -o option to xsltproc</li>
</ul>
<h3>0.12.0: June 18 2001</h3>
<ul>
<li>fixed a dozen of bugs reported</li>
<li>HTML generation should be quite better (requires libxml-2.3.11 upgrade
too)</li>
<li>William fixed some problems with document()</li>
<li>Fix namespace nodes selection and copy (requires libxml-2.3.11 upgrade
too)</li>
<li>John Fleck added a<a href="tutorial/libxslttutorial.html">
tutorial</a></li>
<li>Fixes for namespace handling when evaluating variables</li>
<li>XInclude global flag added to process XInclude on document() if
requested</li>
<li>made xsltproc --version more detailed</li>
</ul>
<h3>0.11.0: June 1 2001</h3>
<p>Mostly a bug fix release.</p>
<ul>
<li>integration of catalogs from xsltproc</li>
<li>added --version to xsltproc for bug reporting</li>
<li>fixed errors when handling ID in external parsed entities</li>
<li>document() should hopefully work correctly but ...</li>
<li>fixed bug with PI and comments processing</li>
<li>William fixed the XPath string functions when using unicode</li>
</ul>
<h3>0.10.0: May 19 2001</h3>
<ul>
<li>cleanups to make stylesheet read-only (not 100% complete)</li>
<li>fixed URI resolution in document()</li>
<li>force all XPath expression to be compiled at stylesheet parsing time,
even if unused ...</li>
<li>Fixed HTML default output detection</li>
<li>Fixed double attribute generation #54446</li>
<li>Fixed {{ handling in attributes #54451</li>
<li>More tests and speedups for DocBook document transformations</li>
<li>Fixed a really bad race like bug in xsltCopyTreeList()</li>
<li>added a documentation on the libxslt internals</li>
<li>William Brack and Bjorn Reese improved format-number()</li>
<li>Fixed multiple sort, it should really work now</li>
<li>added a --docbook option for SGML DocBook input (hackish)</li>
<li>a number of other bug fixes and regression test added as people were
submitting them</li>
</ul>
<h3>0.9.0: May 3 2001</h3>
<ul>
<li>lot of various bugfixes, extended the regression suite</li>
<li>xsltproc should work with multiple params</li>
<li>added an option to use xsltproc with HTML input</li>
<li>improved the stylesheet compilation, processing of complex stylesheets
should be faster</li>
<li>using the same stylesheet for concurrent processing on multithreaded
programs should work now</li>
<li>fixed another batch of namespace handling problems</li>
<li>Implemented multiple level of sorting</li>
</ul>
<h3>0.8.0: Apr 22 2001</h3>
<ul>
<li>fixed ansidecl.h problem</li>
<li>fixed unparsed-entity-uri() and generate-id()</li>
<li>sort semantic fixes and priority prob from William M. Brack</li>
<li>fixed namespace handling problems in XPath expression computations
(requires libxml-2.3.7)</li>
<li>fixes to current() and key()</li>
<li>other, smaller fixes, lots of testing with N Walsh DocBook HTML
stylesheets</li>
</ul>
<h3>0.7.0: Apr 10 2001</h3>
<ul>
<li>cleanup using stricter compiler flags</li>
<li>command line parameter passing</li>
<li>fix to xsltApplyTemplates from William M. Brack</li>
<li>added the XSLTMark in the regression tests as well as document()</li>
</ul>
<h3>0.6.0: Mar 22 2001</h3>
<ul>
<li>another beta</li>
<li>requires 2.3.5, which provide XPath expression compilation support</li>
<li>document() extension should function properly</li>
<li>fixed a number or reported bugs</li>
</ul>
<h3>0.5.0: Mar 10 2001</h3>
<ul>
<li>fifth beta</li>
<li>some optimization work, for the moment 2 XSLT transform cannot use the
same stylesheet at the same time (to be fixed)</li>
<li>fixed problems with handling of tree results</li>
<li>fixed a reported strip-spaces problem</li>
<li>added more reported/fixed bugs to the test suite</li>
<li>incorporated William M. Brack fix for imports and global variables as
well as patch for with-param support in apply-templates</li>
<li>a bug fix on for-each</li>
</ul>
<h3>0.4.0: Mar 1 2001</h3>
<ul>
<li>fourth beta test, released at the same time of libxml2-2.3.3</li>
<li>bug fixes</li>
<li>some optimization</li>
<li>started implement extension support, not finished</li>
<li>implemented but not tested multiple file output</li>
</ul>
<h3>0.3.0: Feb 24 2001</h3>
<ul>
<li>third beta test, released at the same time of libxml2-2.3.2</li>
<li>lot of bug fixes</li>
<li>some optimization</li>
<li>added DocBook XSL based testsuite</li>
</ul>
<h3>0.2.0: Feb 15 2001</h3>
<ul>
<li>second beta version, released at the same time as libxml2-2.3.1</li>
<li>getting close to feature completion, lot of bug fixes, some in the HTML
and XPath support of libxml</li>
<li>start becoming usable for real work. This version can now regenerate
the XML 2e HTML from the original XML sources and the associated
stylesheets (in <a
href="http://www.w3.org/TR/REC-xml#b4d250b6c21">section I of the XML
REC</a>)</li>
<li>Still misses extension element/function/prefixes support. Support of
key() and document() is not complete</li>
</ul>
<h3>0.1.0: Feb 8 2001</h3>
<ul>
<li>first beta version, released at the same time as libxml2-2.3.0</li>
<li>lots of bug fixes, first "testing" version, but incomplete</li>
</ul>
<h3>0.0.1: Jan 25 2001</h3>
<ul>
<li>first alpha version released at the same time as libxml2-2.2.12</li>
<li>Framework in place, should work on simple examples, but far from being
feature complete</li>
</ul>
<h2><a name="xsltproc">The xsltproc tool</a></h2>
<p>This program is the simplest way to use libxslt: from the command line. It
is also used for doing the regression tests of the library.</p>
<p>It takes as first argument the path or URL to an XSLT stylesheet, the next
arguments are filenames or URIs of the inputs to be processed. The output of
the processing is redirected on the standard output. There is actually a few
more options available:</p>
<pre>orchis:~ -> xsltproc
Usage: xsltproc [options] stylesheet file [file ...]
Options:
--version or -V: show the version of libxml and libxslt used
--verbose or -v: show logs of what's happening
--output file or -o file: save to a given file
--timing: display the time used
--repeat: run the transformation 20 times
--debug: dump the tree of the result instead
--novalid: skip the Dtd loading phase
--noout: do not dump the result
--maxdepth val : increase the maximum depth
--html: the input document is(are) an HTML file(s)
--docbook: the input document is SGML docbook
--param name value : pass a (parameter,value) pair
--nonet refuse to fetch DTDs or entities over network
--warnnet warn against fetching over the network
--catalogs : use the catalogs from $SGML_CATALOG_FILES
--xinclude : do XInclude processing on document intput
--profile or --norman : dump profiling informations
orchis:~ -></pre>
<h2><a name="API">The programming API</a></h2>
<p>Okay this section is clearly incomplete. But integrating libxslt into your
application should be relatively easy. First check the few steps described
below, then for more detailed informations, look at the<a
href="html/libxslt-lib.html"> generated pages</a> for the API and the source
of libxslt/xsltproc.c and the <a
href="tutorial/libxslttutorial.html">tutorial</a>.</p>
<p>Basically doing an XSLT transformation can be done in a few steps:</p>
<ol>
<li>configure the parser for XSLT:
<p>xmlSubstituteEntitiesDefault(1);</p>
<p>xmlLoadExtDtdDefaultValue = 1;</p>
</li>
<li>parse the stylesheet with xsltParseStylesheetFile()</li>
<li>parse the document with xmlParseFile()</li>
<li>apply the stylesheet using xsltApplyStylesheet()</li>
<li>save the result using xsltSaveResultToFile() if needed set
xmlIndentTreeOutput to 1</li>
</ol>
<p>Steps 2,3, and 5 will probably need to be changed depending on you
processing needs and environment for example if reading/saving from/to
memory, or if you want to apply XInclude processing to the stylesheet or
input documents.</p>
<h2><a name="Internals">Library internals</a></h2>
<h3>Table of contents</h3>
<ul>
<li><a href="internals.html#Introducti">Introduction</a></li>
<li><a href="internals.html#Basics">Basics</a></li>
<li><a href="internals.html#Keep">Keep it simple stupid</a></li>
<li><a href="internals.html#libxml">The libxml nodes</a></li>
<li><a href="internals.html#XSLT">The XSLT processing steps</a></li>
<li><a href="internals.html#XSLT1">The XSLT stylesheet compilation</a></li>
<li><a href="internals.html#XSLT2">The XSLT template compilation</a></li>
<li><a href="internals.html#processing">The processing itself</a></li>
<li><a href="internals.html#XPath">XPath expressions compilation</a></li>
<li><a href="internals.html#XPath1">XPath interpretation</a></li>
<li><a href="internals.html#Descriptio">Description of XPath
Objects</a></li>
<li><a href="internals.html#XPath3">XPath functions</a></li>
<li><a href="internals.html#stack">The variables stack frame</a></li>
<li><a href="internals.html#Extension">Extension support</a></li>
<li><a href="internals.html#Futher">Further reading</a></li>
<li><a href="internals.html#TODOs">TODOs</a></li>
</ul>
<h3><a name="Introducti2">Introduction</a></h3>
<p>This document describes the processing of <a
href="http://xmlsoft.org/XSLT/">libxslt</a>, the <a
href="http://www.w3.org/TR/xslt">XSLT</a> C library developed for the <a
href="http://www.gnome.org/">Gnome</a> project.</p>
<p>Note: this documentation is by definition incomplete and I am not good at
spelling, grammar, so patches and suggestions are <a
href="mailto:veillard@redhat.com">really welcome</a>.</p>
<h3><a name="Basics1">Basics</a></h3>
<p>XSLT is a transformation language. It takes an input document and a
stylesheet document and generates an output document:</p>
<p align="center"><img src="processing.gif"
alt="the XSLT processing model"></p>
<p>Libxslt is written in C. It relies on <a
href="http://www.xmlsoft.org/">libxml</a>, the XML C library for Gnome, for
the following operations:</p>
<ul>
<li>parsing files</li>
<li>building the in-memory DOM structure associated with the documents
handled</li>
<li>the XPath implementation</li>
<li>serializing back the result document to XML and HTML. (Text is handled
directly.)</li>
</ul>
<h3><a name="Keep1">Keep it simple stupid</a></h3>
<p>Libxslt is not very specialized. It is built under the assumption that all
nodes from the source and output document can fit in the virtual memory of
the system. There is a big trade-off there. It is fine for reasonably sized
documents but may not be suitable for large sets of data. The gain is that it
can be used in a relatively versatile way. The input or output may never be
serialized, but the size of documents it can handle are limited by the size
of the memory available.</p>
<p>More specialized memory handling approaches are possible, like building
the input tree from a serialization progressively as it is consumed,
factoring repetitive patterns, or even on-the-fly generation of the output as
the input is parsed but it is possible only for a limited subset of the
stylesheets. In general the implementation of libxslt follows the following
pattern:</p>
<ul>
<li>KISS (keep it simple stupid)</li>
<li>when there is a clear bottleneck optimize on top of this simple
framework and refine only as much as is needed to reach the expected
result</li>
</ul>
<p>The result is not that bad, clearly one can do a better job but more
specialized too. Most optimization like building the tree on-demand would
need serious changes to the libxml XPath framework. An easy step would be to
serialize the output directly (or call a set of SAX-like output handler to
keep this a flexible interface) and hence avoid the memory consumption of the
result.</p>
<h3><a name="libxml">The libxml nodes</a></h3>
<p>DOM-like trees, as used and generated by libxml and libxslt, are
relatively complex. Most node types follow the given structure except a few
variations depending on the node type:</p>
<p align="center"><img src="node.gif" alt="description of a libxml node"></p>
<p>Nodes carry a <strong>name</strong> and the node <strong>type</strong>
indicates the kind of node it represents, the most common ones are:</p>
<ul>
<li>document nodes</li>
<li>element nodes</li>
<li>text nodes</li>
</ul>
<p>For the XSLT processing, entity nodes should not be generated (i.e. they
should be replaced by their content). Most nodes also contains the following
"navigation" informations:</p>
<ul>
<li>the containing <strong>doc</strong>ument</li>
<li>the <strong>parent</strong> node</li>
<li>the first <strong>children</strong> node</li>
<li>the <strong>last</strong> children node</li>
<li>the <strong>prev</strong>ious sibling</li>
<li>the following sibling (<strong>next</strong>)</li>
</ul>
<p>Elements nodes carries the list of attributes in the properties, an
attribute itself holds the navigation pointers and the children list (the
attribute value is not represented as a simple string to allow usage of
entities references).</p>
<p>The <strong>ns</strong> points to the namespace declaration for the
namespace associated to the node, <strong>nsDef</strong> is the linked list
of namespace declaration present on element nodes.</p>
<p>Most nodes also carry an <strong>_private</strong> pointer which can be
used by the application to hold specific data on this node.</p>
<h3><a name="XSLT">The XSLT processing steps</a></h3>
<p>There are a few steps which are clearly decoupled at the interface
level:</p>
<ol>
<li>parse the stylesheet and generate a DOM tree</li>
<li>take the stylesheet tree and build a compiled version of it (the
compilation phase)</li>
<li>take the input and generate a DOM tree</li>
<li>process the stylesheet against the input tree and generate an output
tree</li>
<li>serialize the output tree</li>
</ol>
<p>A few things should be noted here:</p>
<ul>
<li>the steps 1/ 3/ and 5/ are optional</li>
<li>the stylesheet obtained at 2/ can be reused by multiple processing 4/
(and this should also work in threaded programs)</li>
<li>the tree provided in 2/ should never be freed using xmlFreeDoc, but by
freeing the stylesheet.</li>
<li>the input tree 4/ is not modified except the _private field which may
be used for labelling keys if used by the stylesheet</li>
</ul>
<h3><a name="XSLT1">The XSLT stylesheet compilation</a></h3>
<p>This is the second step described. It takes a stylesheet tree, and
"compiles" it. This associates to each node a structure stored in the
_private field and containing information computed in the stylesheet:</p>
<p align="center"><img src="stylesheet.gif"
alt="a compiled XSLT stylesheet"></p>
<p>One xsltStylesheet structure is generated per document parsed for the
stylesheet. XSLT documents allow includes and imports of other documents,
imports are stored in the <strong>imports</strong> list (hence keeping the
tree hierarchy of includes which is very important for a proper XSLT
processing model) and includes are stored in the <strong>doclist</strong>
list. An imported stylesheet has a parent link to allow browsing of the
tree.</p>
<p>The DOM tree associated to the document is stored in <strong>doc</strong>.
It is preprocessed to remove ignorable empty nodes and all the nodes in the
XSLT namespace are subject to precomputing. This usually consist of
extracting all the context information from the context tree (attributes,
namespaces, XPath expressions), and storing them in an xsltStylePreComp
structure associated to the <strong>_private</strong> field of the node.</p>
<p>A couple of notable exceptions to this are XSLT template nodes (more on
this later) and attribute value templates. If they are actually templates,
the value cannot be computed at compilation time. (Some preprocessing could
be done like isolation and preparsing of the XPath subexpressions but it's
not done, yet.)</p>
<p>The xsltStylePreComp structure also allows storing of the precompiled form
of an XPath expression that can be associated to an XSLT element (more on
this later).</p>
<h3><a name="XSLT2">The XSLT template compilation</a></h3>
<p>A proper handling of templates lookup is one of the keys of fast XSLT
processing. (Given a node in the source document this is the process of
finding which templates should be applied to this node.) Libxslt follows the
hint suggested in the <a href="http://www.w3.org/TR/xslt#patterns">5.2
Patterns</a> section of the XSLT Recommendation, i.e. it doesn't evaluate it
as an XPath expression but tokenizes it and compiles it as a set of rules to
be evaluated on a candidate node. There usually is an indication of the node
name in the last step of this evaluation and this is used as a key check for
the match. As a result libxslt builds a relatively more complex set of
structures for the templates:</p>
<p align="center"><img src="templates.gif"
alt="The templates related structure"></p>
<p>Let's describe a bit more closely what is built. First the xsltStylesheet
structure holds a pointer to the template hash table. All the XSLT patterns
compiled in this stylesheet are indexed by the value of the the target
element (or attribute, pi ...) name, so when a element or an attribute "foo"
needs to be processed the lookup is done using the name as a key.</p>
<p>Each of the patterns is compiled into an xsltCompMatch structure. It holds
the set of rules based on the tokenization of the pattern stored in reverse
order (matching is easier this way). It also holds some information about the
previous matches used to speed up the process when one iterates over a set of
siblings. (This optimization may be defeated by trashing when running
threaded computation, it's unclear that this is a big deal in practice.)
Predicate expressions are not compiled at this stage, they may be at run-time
if needed, but in this case they are compiled as full XPath expressions (the
use of some fixed predicate can probably be optimized, they are not yet).</p>
<p>The xsltCompMatch are then stored in the hash table, the clash list is
itself sorted by priority of the template to implement "naturally" the XSLT
priority rules.</p>
<p>Associated to the compiled pattern is the xsltTemplate itself containing
the information required for the processing of the pattern including, of
course, a pointer to the list of elements used for building the pattern
result.</p>
<p>Last but not least a number of patterns do not fit in the hash table
because they are not associated to a name, this is the case for patterns
applying to the root, any element, any attributes, text nodes, pi nodes, keys
etc. Those are stored independently in the stylesheet structure as separate
linked lists of xsltCompMatch.</p>
<h3><a name="processing">The processing itself</a></h3>
<p>The processing is defined by the XSLT specification (the basis of the
algorithm is explained in <a
href="http://www.w3.org/TR/xslt#section-Introduction">the Introduction</a>
section). Basically it works by taking the root of the input document and
applying the following algorithm:</p>
<ol>
<li>Finding the template applying to it. This is a lookup in the template
hash table, walking the hash list until the node satisfies all the steps
of the pattern, then checking the appropriate(s) global templates to see
if there isn't a higher priority rule to apply</li>
<li>If there is no template, apply the default rule (recurse on the
children)</li>
<li>else walk the content list of the selected templates, for each of them:
<ul>
<li>if the node is in the XSLT namespace then the node has a _private
field pointing to the preprocessed values, jump to the specific
code</li>
<li>if the node is in an extension namespace, look up the associated
behavior</li>
<li>otherwise copy the node.</li>
</ul>
<p>The closure is usually done through the XSLT
<strong>apply-templates</strong> construct recursing by applying the
adequate template on the input node children or on the result of an
associated XPath selection lookup.</p>
</li>
</ol>
<p>Note that large parts of the input tree may not be processed by a given
stylesheet and that on the opposite some may be processed multiple times.
(This often is the case when a Table of Contents is built).</p>
<p>The module <code>transform.c</code> is the one implementing most of this
logic. <strong>xsltApplyStylesheet()</strong> is the entry point, it
allocates an xsltTransformContext containing the following:</p>
<ul>
<li>a pointer to the stylesheet being processed</li>
<li>a stack of templates</li>
<li>a stack of variables and parameters</li>
<li>an XPath context</li>
<li>the template mode</li>
<li>current document</li>
<li>current input node</li>
<li>current selected node list</li>
<li>the current insertion points in the output document</li>
<li>a couple of hash tables for extension elements and functions</li>
</ul>
<p>Then a new document gets allocated (HTML or XML depending on the type of
output), the user parameters and global variables and parameters are
evaluated. Then <strong>xsltProcessOneNode()</strong> which implements the
1-2-3 algorithm is called on the root element of the input. Step 1/ is
implemented by calling <strong>xsltGetTemplate()</strong>, step 2/ is
implemented by <strong>xsltDefaultProcessOneNode()</strong> and step 3/ is
implemented by <strong>xsltApplyOneTemplate()</strong>.</p>
<h3><a name="XPath">XPath expression compilation</a></h3>
<p>The XPath support is actually implemented in the libxml module (where it
is reused by the XPointer implementation). XPath is a relatively classic
expression language. The only uncommon feature is that it is working on XML
trees and hence has specific syntax and types to handle them.</p>
<p>XPath expressions are compiled using <strong>xmlXPathCompile()</strong>.
It will take an expression string in input and generate a structure
containing the parsed expression tree, for example the expression:</p>
<pre>/doc/chapter[title='Introduction']</pre>
<p>will be compiled as</p>
<pre>Compiled Expression : 10 elements
SORT
COLLECT 'child' 'name' 'node' chapter
COLLECT 'child' 'name' 'node' doc
ROOT
PREDICATE
SORT
EQUAL =
COLLECT 'child' 'name' 'node' title
NODE
ELEM Object is a string : Introduction
COLLECT 'child' 'name' 'node' title
NODE</pre>
<p>This can be tested using the <code>testXPath</code> command (in the
libxml codebase) using the <code>--tree</code> option.</p>
<p>Again, the KISS approach is used. No optimization is done. This could be
an interesting thing to add. <a
href="http://www-106.ibm.com/developerworks/library/x-xslt2/?dwzone=x?open&l=132%2ct=gr%2c+p=saxon">Michael
Kay describes</a> a lot of possible and interesting optimizations done in
Saxon which would be possible at this level. I'm unsure they would provide
much gain since the expressions tends to be relatively simple in general and
stylesheets are still hand generated. Optimizations at the interpretation
sounds likely to be more efficient.</p>
<h3><a name="XPath1">XPath interpretation</a></h3>
<p>The interpreter is implemented by <strong>xmlXPathCompiledEval()</strong>
which is the front-end to <strong>xmlXPathCompOpEval()</strong> the function
implementing the evaluation of the expression tree. This evaluation follows
the KISS approach again. It's recursive and calls
<strong>xmlXPathNodeCollectAndTest()</strong> to collect nodes set when
evaluating a <code>COLLECT</code> node.</p>
<p>An evaluation is done within the framework of an XPath context stored in
an <strong>xmlXPathContext</strong> structure, in the framework of a
transformation the context is maintained within the XSLT context. Its content
follows the requirements from the XPath specification:</p>
<ul>
<li>the current document</li>
<li>the current node</li>
<li>a hash table of defined variables (but not used by XSLT)</li>
<li>a hash table of defined functions</li>
<li>the proximity position (the place of the node in the current node
list)</li>
<li>the context size (the size of the current node list)</li>
<li>the array of namespace declarations in scope (there also is a namespace
hash table but it is not used in the XSLT transformation).</li>
</ul>
<p>For the purpose of XSLT an <strong>extra</strong> pointer has been added
allowing to retrieve the XSLT transformation context. When an XPath
evaluation is about to be performed, an XPath parser context is allocated
containing and XPath object stack (this is actually an XPath evaluation
context, this is a remain of the time where there was no separate parsing and
evaluation phase in the XPath implementation). Here is an overview of the set
of contexts associated to an XPath evaluation within an XSLT
transformation:</p>
<p align="center"><img src="contexts.gif"
alt="The set of contexts associated "></p>
<p>Clearly this is a bit too complex and confusing and should be refactored
at the next set of binary incompatible releases of libxml. For example the
xmlXPathCtxt has a lot of unused parts and should probably be merged with
xmlXPathParserCtxt.</p>
<h3><a name="Descriptio">Description of XPath Objects</a></h3>
<p>An XPath expression manipulates XPath objects. XPath defines the default
types boolean, numbers, strings and node sets. XSLT adds the result tree
fragment type which is basically an unmodifiable node set.</p>
<p>Implementation-wise, libxml follows again a KISS approach, the
xmlXPathObject is a structure containing a type description and the various
possibilities. (Using an enum could have gained some bytes.) In the case of
node sets (or result tree fragments), it points to a separate xmlNodeSet
object which contains the list of pointers to the document nodes:</p>
<p align="center"><img src="object.gif"
alt="An Node set object pointing to "></p>
<p>The <a href="http://xmlsoft.org/html/libxml-xpath.html">XPath API</a> (and
its <a href="http://xmlsoft.org/html/libxml-xpathinternals.html">'internal'
part</a>) includes a number of functions to create, copy, compare, convert or
free XPath objects.</p>
<h3><a name="XPath3">XPath functions</a></h3>
<p>All the XPath functions available to the interpreter are registered in the
function hash table linked from the XPath context. They all share the same
signature:</p>
<pre>void xmlXPathFunc (xmlXPathParserContextPtr ctxt, int nargs);</pre>
<p>The first argument is the XPath interpretation context, holding the
interpretation stack. The second argument defines the number of objects
passed on the stack for the function to consume (last argument is on top of
the stack).</p>
<p>Basically an XPath function does the following:</p>
<ul>
<li>check <code>nargs</code> for proper handling of errors or functions
with variable numbers of parameters</li>
<li>pop the parameters from the stack using <code>obj =
valuePop(ctxt);</code></li>
<li>do the function specific computation</li>
<li>push the result parameter on the stack using <code>valuePush(ctxt,
res);</code></li>
<li>free up the input parameters with
<code>xmlXPathFreeObject(obj);</code></li>
<li>return</li>
</ul>
<p>Sometime the work can be done directly by modifying in-situ the top object
on the stack <code>ctxt->value</code>.</p>
<h3><a name="stack">The XSLT variables stack frame</a></h3>
<p>Not to be confused with XPath object stack, this stack holds the XSLT
variables and parameters as they are defined through the recursive calls of
call-template, apply-templates and default templates. This is used to define
the scope of variables being called.</p>
<p>This part seems to be the most urgent attention right now, first it is
done in a very inefficient way since the location of the variables and
parameters within the stylesheet tree is still done at run time (it really
should be done statically at compile time), and I am still unsure that my
understanding of the template variables and parameter scope is actually
right.</p>
<p>This part of the documentation is still to be written once this part of
the code will be stable. <span
style="background-color: #FF0000">TODO</span></p>
<h3><a name="Extension">Extension support</a></h3>
<p>There is a separate document explaining <a href="extensions.html">how the
extension support works</a>.</p>
<h3><a name="Futher">Further reading</a></h3>
<p>Michael Kay wrote <a
href="http://www-106.ibm.com/developerworks/library/x-xslt2/?dwzone=x?open&l=132%2ct=gr%2c+p=saxon">a
really interesting article on Saxon internals</a> and the work he did on
performance issues. I wishes I had read it before starting libxslt design (I
would probably have avoided a few mistakes and progressed faster). A lot of
the ideas in his papers should be implemented or at least tried in
libxslt.</p>
<p>The <a href="http://xmlsoft.org/">libxml documentation</a>, especially <a
href="http://xmlsoft.org/xmlio.html">the I/O interfaces</a> and the <a
href="http://xmlsoft.org/xmlmem.html">memory management</a>.</p>
<h3><a name="TODOs">TODOs</a></h3>
<p>redesign the XSLT stack frame handling. Far too much work is done at
execution time. Similarly for the attribute value templates handling, at
least the embedded subexpressions ought to be precompiled.</p>
<p>Allow output to be saved to a SAX like output (this notion of SAX like API
for output should be added directly to libxml).</p>
<p>Implement and test some of the optimization explained by Michael Kay
especially:</p>
<ul>
<li>static slot allocation on the stack frame</li>
<li>specific boolean interpretation of an XPath expression</li>
<li>some of the sorting optimization</li>
<li>Lazy evaluation of location path. (this may require more changes but
sounds really interesting. XT does this too.)</li>
<li>Optimization of an expression tree (This could be done as a completely
independent module.)</li>
</ul>
<p></p>
<p>Error reporting, there is a lot of case where the XSLT specification
specify that a given construct is an error are not checked adequately by
libxslt. Basically one should do a complete pass on the XSLT spec again and
add all tests to the stylesheet compilation. Using the DTD provided in the
appendix and making direct checks using the libxml validation API sounds a
good idea too (though one should take care of not raising errors for
elements/attributes in different namespaces).</p>
<p>Double check all the places where the stylesheet compiled form might be
modified at run time (extra removal of blanks nodes, hint on the
xsltCompMatch).</p>
<p></p>
<h2><a name="Extensions">Writing extensions</a></h2>
<h3>Table of content</h3>
<ul>
<li><a href="extensions.html#Introducti">Introduction</a></li>
<li><a href="extensions.html#Basics">Basics</a></li>
<li><a href="extensions.html#Keep">Extension modules</a></li>
<li><a href="extensions.html#Registerin">Registering a module</a></li>
<li><a href="extensions.html#module">Loading a module</a></li>
<li><a href="extensions.html#Registerin1">Registering an extension
function</a></li>
<li><a href="extensions.html#Implementi">Implementing an extension
function</a></li>
<li><a href="extensions.html#Examples">Examples for extension
functions</a></li>
<li><a href="extensions.html#Registerin2">Registering an extension
element</a></li>
<li><a href="extensions.html#Implementi1">Implementing an extension
element</a></li>
<li><a href="extensions.html#Example">Example for extension
elements</a></li>
<li><a href="extensions.html#shutdown">The shutdown of a module</a></li>
<li><a href="extensions.html#Future">Future work</a></li>
</ul>
<h3><a name="Introducti1">Introduction</a></h3>
<p>This document describes the work needed to write extensions to the
standard XSLT library for use with <a
href="http://xmlsoft.org/XSLT/">libxslt</a>, the <a
href="http://www.w3.org/TR/xslt">XSLT</a> C library developped for the <a
href="http://www.gnome.org/">Gnome</a> project.</p>
<p>Before starting reading this document it is highly recommended to get
familiar with <a href="internals.html">the libxslt internals</a>.</p>
<p>Note: this documentation is by definition incomplete and I am not good at
spelling, grammar, so patches and suggestions are <a
href="mailto:veillard@redhat.com">really welcome</a>.</p>
<h3><a name="Basics">Basics</a></h3>
<p>The <a href="http://www.w3.org/TR/xslt">XSLT specification</a> provides
two <a href="http://www.w3.org/TR/xslt">ways to extend an XSLT engine</a>:</p>
<ul>
<li>providing <a href="http://www.w3.org/TR/xslt">new extension
functions</a> which can be called from XPath expressions</li>
<li>providing <a href="http://www.w3.org/TR/xslt">new extension
elements</a> which can be inserted in stylesheets</li>
</ul>
<p>In both cases the extensions need to be associated to a new namespace,
i.e. an URI used as the name for the extension's namespace (there is no need
to have a resource there for this to work).</p>
<p>libxslt provides a few extensions itself, either in libxslt namespace
"http://xmlsoft.org/XSLT/" or in other namespace for well known extensions
provided by other XSLT processors like Saxon, Xalan or XT.</p>
<h3><a name="Keep">Extension modules</a></h3>
<p>Since extensions are bound to a namespace name, usually sets of extensions
coming from a given source are using the same namespace name defining in
practice a group of extensions providing elements, functions or both. From
libxslt point of view those are considered as an "extension module", and most
of the APIs work at a module point of view.</p>
<p>Registration of new functions or elements are bound to the activation of
the module, this is currently done by declaring the namespace as an extension
by using the attribute <code>extension-element-prefixes</code> on the
<code><a href="http://www.w3.org/TR/xslt">xsl:stylesheet</a></code>
element.</p>
<p>And extension module is defined by 3 objects:</p>
<ul>
<li>the namespace name associated</li>
<li>an initialization function</li>
<li>a shutdown function</li>
</ul>
<h3><a name="Registerin">Registering a module</a></h3>
<p>Currently a libxslt module has to be compiled within the application using
libxslt, there is no code to load dynamically shared libraries associated to
namespace (this may be added but is likely to become a portability
nightmare).</p>
<p>So the current way to register a module is to link the code implementing
it with the application and to call a registration function:</p>
<pre>int xsltRegisterExtModule(const xmlChar *URI,
xsltExtInitFunction initFunc,
xsltExtShutdownFunction shutdownFunc);</pre>
<p>The associated header is read by:</p>
<pre>#include<libxslt/extensions.h></pre>
<p>which also defines the type for the initialization and shutdown
functions</p>
<h3><a name="module">Loading a module</a></h3>
<p>Once the module URI has been registered and if the XSLT processor detects
that a given stylesheet needs the functionalities of an extended module, this
one is initialized.</p>
<p>The xsltExtInitFunction type defines the interface for an initialization
function:</p>
<pre>/**
* xsltExtInitFunction:
* @ctxt: an XSLT transformation context
* @URI: the namespace URI for the extension
*
* A function called at initialization time of an XSLT
* extension module
*
* Returns a pointer to the module specific data for this
* transformation
*/
typedef void *(*xsltExtInitFunction)(xsltTransformContextPtr ctxt,
const xmlChar *URI);</pre>
<p>There are 3 things to notice:</p>
<ul>
<li>the function gets passed the namespace name URI as an argument, this
allow a single function to provide the initialization for multiple
logical modules</li>
<li>it also gets passed a transformation context, the initialization is
done at run time before any processing occurs on the stylesheet but it
will be invoked separately each time for each transformation</li>
<li>it returns a pointer, this can be used to store module specific
informations which can be retrieved later when a function or an element
from the extension are used, an obvious example is a connection to a
database which should be kept and reused along the transformation. NULL
is a perfectly valid return, there is no way to indicate a failure at
this level</li>
</ul>
<p>What this function is expected to do is:</p>
<ul>
<li>prepare the context for this module (like opening the database
connection)</li>
<li>register the extensions specific to this module</li>
</ul>
<h3><a name="Registerin1">Registering an extension function</a></h3>
<p>There is a single call to do this registration:</p>
<pre>int xsltRegisterExtFunction(xsltTransformContextPtr ctxt,
const xmlChar *name,
const xmlChar *URI,
xmlXPathEvalFunc function);</pre>
<p>The registration is bound to a single transformation instance referred by
ctxt, name is the UTF8 encoded name for the NCName of the function, and URI
is the namespace name for the extension (no checking is done, a module could
register functions or elements from a different namespace, but it is not
recommended).</p>
<h3><a name="Implementi">Implementing an extension function</a></h3>
<p>The implementation of the function must have the signature of a libxml
XPath function:</p>
<pre>/**
* xmlXPathEvalFunc:
* @ctxt: an XPath parser context
* @nargs: the number of arguments passed to the function
*
* an XPath evaluation function, the parameters are on the
* XPath context stack
*/
typedef void (*xmlXPathEvalFunc)(xmlXPathParserContextPtr ctxt,
int nargs);</pre>
<p>The context passed to an XPath function is not an XSLT context but an <a
href="internals.html#XPath1">XPath context</a>. However it is possible to
find one from the other:</p>
<ul>
<li>The function xsltXPathGetTransformContext provide this lookup facility:
<pre>xsltTransformContextPtr
xsltXPathGetTransformContext
(xmlXPathParserContextPtr ctxt);</pre>
</li>
<li>The <code>xmlXPathContextPtr</code> associated to an
<code>xsltTransformContext</code> is stored in the <code>xpathCtxt</code>
field.</li>
</ul>
<p>The first thing an extension function may want to do is to check the
arguments passed on the stack, the <code>nargs</code> will precise how many
of them were provided on the XPath expression. The macros valuePop will
extract them from the XPath stack:</p>
<pre>#include <libxml/xpath.h>
#include <libxml/xpathInternals.h>
xmlXPathObjectPtr obj = valuePop(ctxt); </pre>
<p>Note that <code>ctxt</code> is the XPath context not the XSLT one. It is
then possible to examine the content of the value. Check <a
href="internals.html#Descriptio">the description of XPath objects</a> if
necessary. The following is a common sequcnce checking whether the argument
passed is a string and converting it using the built-in XPath
<code>string()</code> function if this is not the case:</p>
<pre>if (obj->type != XPATH_STRING) {
valuePush(ctxt, obj);
xmlXPathStringFunction(ctxt, 1);
obj = valuePop(ctxt);
}</pre>
<p>Most common XPath functions are available directly at the C level and are
exported either in <code><libxml/xpath.h></code> or in
<code><libxml/xpathInternals.h></code>.</p>
<p>The extension function may also need to retrieve the data associated to
this module instance (the database connection in the previous example) this
can be done using the xsltGetExtData:</p>
<pre>void * xsltGetExtData(xsltTransformContextPtr ctxt,
const xmlChar *URI);</pre>
<p>again the URI to be provided is the one used which was used when
registering the module.</p>
<p>Once the function finishes, don't forget to:</p>
<ul>
<li>push the return value on the stack using <code>valuePush(ctxt,
obj)</code></li>
<li>deallocate the parameters passed to the function using
<code>xmlXPathFreeObject(obj)</code></li>
</ul>
<h3><a name="Examples">Examples for extension functions</a></h3>
<p>The module libxslt/functions.c containsthe sources of the XSLT built-in
functions, including document(), key(), generate-id(), etc. as well as a full
example module at the end. Here is the test function implementation for the
libxslt:test function:</p>
<pre>/**
* xsltExtFunctionTest:
* @ctxt: the XPath Parser context
* @nargs: the number of arguments
*
* function libxslt:test() for testing the extensions support.
*/
static void
xsltExtFunctionTest(xmlXPathParserContextPtr ctxt, int nargs)
{
xsltTransformContextPtr tctxt;
void *data;
tctxt = xsltXPathGetTransformContext(ctxt);
if (tctxt == NULL) {
xsltGenericError(xsltGenericErrorContext,
"xsltExtFunctionTest: failed to get the transformation context\n");
return;
}
data = xsltGetExtData(tctxt, (const xmlChar *) XSLT_DEFAULT_URL);
if (data == NULL) {
xsltGenericError(xsltGenericErrorContext,
"xsltExtFunctionTest: failed to get module data\n");
return;
}
#ifdef WITH_XSLT_DEBUG_FUNCTION
xsltGenericDebug(xsltGenericDebugContext,
"libxslt:test() called with %d args\n", nargs);
#endif
}</pre>
<h3><a name="Registerin2">Registering an extension function</a></h3>
<p>There is a single call to do this registration:</p>
<pre>int xsltRegisterExtElement(xsltTransformContextPtr ctxt,
const xmlChar *name,
const xmlChar *URI,
xsltTransformFunction function);</pre>
<p>It is similar to the mechanism used to register an extension function,
except that the signature of an extension element implementation is
different.</p>
<p>The registration is bound to a single transformation instance referred by
ctxt, name is the UTF8 encoded name for the NCName of the element, and URI is
the namespace name for the extension (no checking is done, a module could
register elements for a different namespace, but it is not recommended).</p>
<h3><a name="Implementi1">Implementing an extension element</a></h3>
<p>The implementation of the element must have the signature of an XSLT
transformation function:</p>
<pre>/**
* xsltTransformFunction:
* @ctxt: the XSLT transformation context
* @node: the input node
* @inst: the stylesheet node
* @comp: the compiled information from the stylesheet
*
* signature of the function associated to elements part of the
* stylesheet language like xsl:if or xsl:apply-templates.
*/
typedef void (*xsltTransformFunction)
(xsltTransformContextPtr ctxt,
xmlNodePtr node,
xmlNodePtr inst,
xsltStylePreCompPtr comp);</pre>
<p>The first argument is the XSLT transformation context. The second and
third arguments are xmlNodePtr i.e. internal memory <a
href="internals.html#libxml">representation of XML nodes</a>. They are
respectively <code>node</code> from the the input document being transformed
by the stylesheet and <code>inst</code> the extension element in the
stylesheet. The last argument is <code>comp</code> a pointer to a precompiled
representation of <code>inst</code> but usually for extension function this
value is <code>NULL</code> by default (it could be added and associated to
the instruction in <code>inst->_private</code>).</p>
<p>The same functions are available from a function implementing an extension
element as in an extension function, including
<code>xsltGetExtData()</code>.</p>
<p>The goal of extension element being usually to enrich the generated
output, it is expected that they will grow the currently generated output
tree, this can be done by grabbing ctxt->insert which is the current
libxml node being generated (Note this can also be the intermediate value
tree being built for example to initialize a variable, the processing should
be similar). The functions for libxml tree manipulation from <a
href="http://xmlsoft.org/html/libxml-tree.html"><libxml/tree.h></a> can
be employed to extend or modify the tree, but it is required to preserve the
insertion node and its ancestors since there is existing pointers to those
elements still in use in the XSLT template execution stack.</p>
<h3><a name="Example">Example for extension elements</a></h3>
<p>The module libxslt/transform.c containsthe sources of the XSLT built-in
elements, including xsl:element, xsl:attribute, xsl:if, etc. There is a small
but full example in functions.c providing the implementation for the
libxslt:test element, it will output a comment in the result tree:</p>
<pre>/**
* xsltExtElementTest:
* @ctxt: an XSLT processing context
* @node: The current node
* @inst: the instruction in the stylesheet
* @comp: precomputed informations
*
* Process a libxslt:test node
*/
static void
xsltExtElementTest(xsltTransformContextPtr ctxt, xmlNodePtr node,
xmlNodePtr inst,
xsltStylePreCompPtr comp)
{
xmlNodePtr comment;
if (ctxt == NULL) {
xsltGenericError(xsltGenericErrorContext,
"xsltExtElementTest: no transformation context\n");
return;
}
if (node == NULL) {
xsltGenericError(xsltGenericErrorContext,
"xsltExtElementTest: no current node\n");
return;
}
if (inst == NULL) {
xsltGenericError(xsltGenericErrorContext,
"xsltExtElementTest: no instruction\n");
return;
}
if (ctxt->insert == NULL) {
xsltGenericError(xsltGenericErrorContext,
"xsltExtElementTest: no insertion point\n");
return;
}
comment =
xmlNewComment((const xmlChar *)
"libxslt:test element test worked");
xmlAddChild(ctxt->insert, comment);
}</pre>
<h3><a name="shutdown">The shutdown of a module</a></h3>
<p>When the XSLT processor ends a transformation, the shutdown function (if
it exists) of all the modules initialized are called.The
xsltExtShutdownFunction type defines the interface for a shutdown
function:</p>
<pre>/**
* xsltExtShutdownFunction:
* @ctxt: an XSLT transformation context
* @URI: the namespace URI for the extension
* @data: the data associated to this module
*
* A function called at shutdown time of an XSLT extension module
*/
typedef void (*xsltExtShutdownFunction) (xsltTransformContextPtr ctxt,
const xmlChar *URI,
void *data);</pre>
<p>this is really similar to a module initialization function except a third
argument is passed, it's the value that was returned by the initialization
function. This allow to deallocate resources from the module for example
close the connection to the database to keep the same example.</p>
<h3><a name="Future">Future work</a></h3>
<p>Well some of the pieces missing:</p>
<ul>
<li>a way to load shared libraries to instanciate new modules</li>
<li>a better detection of extension function usage and their registration
without having to use the extension prefix which ought to be reserved to
element extensions.</li>
<li>more examples</li>
<li>implementations of the <a href="http://www.exslt.org/">EXSLT</a> common
extension libraries, Thomas Broyer nearly finished implementing them.</li>
</ul>
<p></p>
<h2><a name="Contributi">Contributions</a></h2>
<ul>
<li>Bjorn Reese is the author of the number support and worked on the
XSLTMark support</li>
<li>William Brack was an early adopted, contributed a number of patches and
spent quite some time debugging non-trivial problems in early versions of
libxslt</li>
<li><a href="mailto:izlatkovic@daenet.de">Igor Zlatkovic</a>
is now the maintainer of the Windows port, <a
href="http://www.fh-frankfurt.de/~igor/projects/libxml/index.html">he
provides binaries</a></li>
<li>Thomas Broyer provided a lot of suggestions, and drafted most of the
extension API</li>
<li>John Fleck maintains <a href="tutorial/libxslttutorial.html">a tutorial
for libxslt</a></li>
<li><a
href="http://mail.gnome.org/archives/xml/2001-March/msg00014.html">Matt
Sergeant</a>
developed <a href="http://axkit.org/download/">XML::LibXSLT</a>, a perl
wrapper for libxml2/libxslt as part of the <a
href="http://axkit.com/">AxKit XML application server</a></li>
<li>there is a module for <a
href="http://acs-misc.sourceforge.net/nsxml.html">libxml/libxslt support
in OpenNSD/AOLServer</a></li>
<li><a href="mailto:dkuhlman@cutter.rexx.com">Dave Kuhlman</a>
provides libxml/libxslt <a href="http://www.rexx.com/~dkuhlman">wrappers
for Python</a></li>
</ul>
<p>I'm still waiting for someone to contribute a simple XSLT processing
module for Apache :-)</p>
<p></p>
<p><a href="mailto:daniel@veillard.com">Daniel Veillard</a></p>
</body>
</html>
|
