1 <chapter id="record-model-domxml">
2 <title>&acro.dom; &acro.xml; Record Model and Filter Module</title>
5 The record model described in this chapter applies to the fundamental,
7 record type <literal>&acro.dom;</literal>, introduced in
8 <xref linkend="componentmodulesdom"/>. The &acro.dom; &acro.xml; record model
9 is experimental, and its inner workings might change in future
10 releases of the &zebra; Information Server.
15 <section id="record-model-domxml-filter">
16 <title>&acro.dom; Record Filter Architecture</title>
19 The &acro.dom; &acro.xml; filter uses a standard &acro.dom; &acro.xml; structure as
20 internal data model, and can therefore parse, index, and display
21 any &acro.xml; document type. It is well suited to work on
22 standardized &acro.xml;-based formats such as Dublin Core, MODS, METS,
23 MARCXML, OAI-PMH, RSS, and performs equally well on any other
24 non-standard &acro.xml; format.
27 A parser for binary &acro.marc; records based on the ISO2709 library
28 standard is provided, it transforms these to the internal
29 &acro.marcxml; &acro.dom; representation. Other binary document parsers
30 are planned to follow.
34 The &acro.dom; filter architecture consists of four
35 different pipelines, each being a chain of arbitrarily many successive
36 &acro.xslt; transformations of the internal &acro.dom; &acro.xml;
37 representations of documents.
40 <figure id="record-model-domxml-architecture-fig">
41 <title>&acro.dom; &acro.xml; filter architecture</title>
44 <imagedata fileref="domfilter.pdf" format="PDF" scale="50"/>
47 <imagedata fileref="domfilter.png" format="PNG"/>
50 <!-- Fall back if none of the images can be used -->
52 [Here there should be a diagram showing the &acro.dom; &acro.xml;
53 filter architecture, but is seems that your
54 tool chain has not been able to include the diagram in this
62 <table id="record-model-domxml-architecture-table" frame="top">
63 <title>&acro.dom; &acro.xml; filter pipelines overview</title>
69 <entry>Description</entry>
77 <entry><literal>input</literal></entry>
79 <entry>input parsing and initial
80 transformations to common &acro.xml; format</entry>
81 <entry>Input raw &acro.xml; record buffers, &acro.xml; streams and
82 binary &acro.marc; buffers</entry>
83 <entry>Common &acro.xml; &acro.dom;</entry>
86 <entry><literal>extract</literal></entry>
88 <entry>indexing term extraction
89 transformations</entry>
90 <entry>Common &acro.xml; &acro.dom;</entry>
91 <entry>Indexing &acro.xml; &acro.dom;</entry>
94 <entry><literal>store</literal></entry>
96 <entry> transformations before internal document
98 <entry>Common &acro.xml; &acro.dom;</entry>
99 <entry>Storage &acro.xml; &acro.dom;</entry>
102 <entry><literal>retrieve</literal></entry>
104 <entry>multiple document retrieve transformations from
105 storage to different output
106 formats are possible</entry>
107 <entry>Storage &acro.xml; &acro.dom;</entry>
108 <entry>Output &acro.xml; syntax in requested formats</entry>
115 The &acro.dom; &acro.xml; filter pipelines use &acro.xslt; (and if supported on
116 your platform, even &acro.exslt;), it brings thus full &acro.xpath;
117 support to the indexing, storage and display rules of not only
118 &acro.xml; documents, but also binary &acro.marc; records.
123 <section id="record-model-domxml-pipeline">
124 <title>&acro.dom; &acro.xml; filter pipeline configuration</title>
127 The experimental, loadable &acro.dom; &acro.xml;/&acro.xslt; filter module
128 <literal>mod-dom.so</literal>
129 is invoked by the <filename>zebra.cfg</filename> configuration statement
131 recordtype.xml: dom.db/filter_dom_conf.xml
133 In this example the &acro.dom; &acro.xml; filter is configured to work
134 on all data files with suffix
135 <filename>*.xml</filename>, where the configuration file is found in the
136 path <filename>db/filter_dom_conf.xml</filename>.
139 <para>The &acro.dom; &acro.xslt; filter configuration file must be
140 valid &acro.xml;. It might look like this:
143 <?xml version="1.0" encoding="UTF8"?>
144 <dom xmlns="http://indexdata.com/zebra-2.0">
146 <xmlreader level="1"/>
147 <!-- <marc inputcharset="marc-8"/> -->
150 <xslt stylesheet="common2index.xsl"/>
153 <xslt stylesheet="common2store.xsl"/>
156 <xslt stylesheet="store2dc.xsl"/>
158 <retrieve name="mods">
159 <xslt stylesheet="store2mods.xsl"/>
166 The root &acro.xml; element <literal><dom></literal> and all other &acro.dom;
167 &acro.xml; filter elements are residing in the namespace
168 <literal>xmlns="http://indexdata.com/zebra-2.0"</literal>.
171 All pipeline definition elements - i.e. the
172 <literal><input></literal>,
173 <literal><extract></literal>,
174 <literal><store></literal>, and
175 <literal><retrieve></literal> elements - are optional.
176 Missing pipeline definitions are just interpreted
177 do-nothing identity pipelines.
180 All pipeline definition elements may contain zero or more
181 <literal><![CDATA[<xslt stylesheet="path/file.xsl"/>]]></literal>
182 &acro.xslt; transformation instructions, which are performed
183 sequentially from top to bottom.
184 The paths in the <literal>stylesheet</literal> attributes
185 are relative to zebras working directory, or absolute to the file
190 <section id="record-model-domxml-pipeline-input">
191 <title>Input pipeline</title>
193 The <literal><input></literal> pipeline definition element
194 may contain either one &acro.xml; Reader definition
195 <literal><![CDATA[<xmlreader level="1"/>]]></literal>, used to split
196 an &acro.xml; collection input stream into individual &acro.xml; &acro.dom;
197 documents at the prescribed element level,
198 or one &acro.marc; binary
200 <literal><![CDATA[<marc inputcharset="marc-8"/>]]></literal>, which defines
201 a conversion to &acro.marcxml; format &acro.dom; trees. The allowed values
202 of the <literal>inputcharset</literal> attribute depend on your
203 local <productname>iconv</productname> set-up.
206 Both input parsers deliver individual &acro.dom; &acro.xml; documents to the
207 following chain of zero or more
208 <literal><![CDATA[<xslt stylesheet="path/file.xsl"/>]]></literal>
209 &acro.xslt; transformations. At the end of this pipeline, the documents
210 are in the common format, used to feed both the
211 <literal><extract></literal> and
212 <literal><store></literal> pipelines.
216 <section id="record-model-domxml-pipeline-extract">
217 <title>Extract pipeline</title>
219 The <literal><extract></literal> pipeline takes documents
220 from any common &acro.dom; &acro.xml; format to the &zebra; specific
221 indexing &acro.dom; &acro.xml; format.
222 It may consist of zero ore more
223 <literal><![CDATA[<xslt stylesheet="path/file.xsl"/>]]></literal>
224 &acro.xslt; transformations, and the outcome is handled to the
225 &zebra; core to drive the process of building the inverted
227 <xref linkend="record-model-domxml-canonical-index"/> for
232 <section id="record-model-domxml-pipeline-store">
233 <title>Store pipeline</title>
234 The <literal><store></literal> pipeline takes documents
235 from any common &acro.dom; &acro.xml; format to the &zebra; specific
236 storage &acro.dom; &acro.xml; format.
237 It may consist of zero ore more
238 <literal><![CDATA[<xslt stylesheet="path/file.xsl"/>]]></literal>
239 &acro.xslt; transformations, and the outcome is handled to the
240 &zebra; core for deposition into the internal storage system.
243 <section id="record-model-domxml-pipeline-retrieve">
244 <title>Retrieve pipeline</title>
246 Finally, there may be one or more
247 <literal><retrieve></literal> pipeline definitions, each
248 of them again consisting of zero or more
249 <literal><![CDATA[<xslt stylesheet="path/file.xsl"/>]]></literal>
250 &acro.xslt; transformations. These are used for document
251 presentation after search, and take the internal storage &acro.dom;
252 &acro.xml; to the requested output formats during record present
256 The possible multiple
257 <literal><retrieve></literal> pipeline definitions
258 are distinguished by their unique <literal>name</literal>
259 attributes, these are the literal <literal>schema</literal> or
260 <literal>element set</literal> names used in
261 <ulink url="http://www.loc.gov/standards/sru/srw/">&acro.srw;</ulink>,
262 <ulink url="&url.sru;">&acro.sru;</ulink> and
263 &acro.z3950; protocol queries.
268 <section id="record-model-domxml-canonical-index">
269 <title>Canonical Indexing Format</title>
272 &acro.dom; &acro.xml; indexing comes in two flavors: pure
273 processing-instruction governed plain &acro.xml; documents, and - very
274 similar to the Alvis filter indexing format - &acro.xml; documents
275 containing &acro.xml; <literal><record></literal> and
276 <literal><index></literal> instructions from the magic
277 namespace <literal>xmlns:z="http://indexdata.com/zebra-2.0"</literal>.
280 <section id="record-model-domxml-canonical-index-pi">
281 <title>Processing-instruction governed indexing format</title>
283 <para>The output of the processing instruction driven
284 indexing &acro.xslt; stylesheets must contain
285 processing instructions named
286 <literal>zebra-2.0</literal>.
287 The output of the &acro.xslt; indexing transformation is then
288 parsed using &acro.dom; methods, and the contained instructions are
289 performed on the <emphasis>elements and their
290 subtrees directly following the processing instructions</emphasis>.
293 For example, the output of the command
295 xsltproc dom-index-pi.xsl marc-one.xml
297 might look like this:
300 <?xml version="1.0" encoding="UTF-8"?>
301 <?zebra-2.0 record id=11224466 rank=42?>
303 <?zebra-2.0 index control:0?>
304 <control>11224466</control>
305 <?zebra-2.0 index any:w title:w title:p title:s?>
306 <title>How to program a computer</title>
313 <section id="record-model-domxml-canonical-index-element">
314 <title>Magic element governed indexing format</title>
316 <para>The output of the indexing &acro.xslt; stylesheets must contain
317 certain elements in the magic
318 <literal>xmlns:z="http://indexdata.com/zebra-2.0"</literal>
319 namespace. The output of the &acro.xslt; indexing transformation is then
320 parsed using &acro.dom; methods, and the contained instructions are
321 performed on the <emphasis>magic elements and their
325 For example, the output of the command
327 xsltproc dom-index-element.xsl marc-one.xml
329 might look like this:
332 <?xml version="1.0" encoding="UTF-8"?>
333 <z:record xmlns:z="http://indexdata.com/zebra-2.0"
334 z:id="11224466" z:rank="42">
335 <z:index name="control:0">11224466</z:index>
336 <z:index name="any:w title:w title:p title:s">
337 How to program a computer</z:index>
345 <section id="record-model-domxml-canonical-index-semantics">
346 <title>Semantics of the indexing formats</title>
349 Both indexing formats are defined with equal semantics and
353 <para>&zebra; specific instructions are either
354 processing instructions named
355 <literal>zebra-2.0</literal> or
356 elements contained in the namespace
357 <literal>xmlns:z="http://indexdata.com/zebra-2.0"</literal>.
361 <para>There must be exactly one <literal>record</literal>
362 instruction, which sets the scope for the following,
363 possibly nested <literal>index</literal> instructions.
368 The unique <literal>record</literal> instruction
369 may have additional attributes <literal>id</literal>,
370 <literal>rank</literal> and <literal>type</literal>.
371 Attribute <literal>id</literal> is the value of the opaque ID
372 and may be any string not containing the whitespace character
373 <literal>' '</literal>.
374 The <literal>rank</literal> attribute value must be a
375 non-negative integer. See
376 <xref linkend="administration-ranking"/> .
377 The <literal>type</literal> attribute specifies how the record
378 is to be treated. The following values may be given for
379 <literal>type</literal>:
382 <term><literal>insert</literal></term>
385 The record is inserted. If the record already exists, it is
386 skipped (i.e. not replaced).
391 <term><literal>replace</literal></term>
394 The record is replaced. If the record does not already exist,
395 it is skipped (i.e. not inserted).
400 <term><literal>delete</literal></term>
403 The record is deleted. If the record does not already exist,
404 a warning issued and rest of records are skipped in
405 from the input stream.
410 <term><literal>update</literal></term>
413 The record is inserted or replaced depending on whether the
414 record exists or not. This is the default behavior but may
415 be effectively changed by "outside" the scope of the DOM
416 filter by zebraidx commands or extended services updates.
421 <term><literal>adelete</literal></term>
424 The record is deleted. If the record does not already exist,
425 it is skipped (i.e. nothing is deleted).
429 Requires version 2.0.54 or later.
435 Note that the value of <literal>type</literal> is only used to
436 determine the action if and only if the Zebra indexer is running
437 in "update" mode (i.e zebraidx update) or if the specialUpdate
439 <link linkend="administration-extended-services-z3950">Extended
440 Service Update</link> is used.
441 For this reason a specialUpdate may end up deleting records!
445 <para> Multiple and possible nested <literal>index</literal>
446 instructions must contain at least one
447 <literal>indexname:indextype</literal>
448 pair, and may contain multiple such pairs separated by the
449 whitespace character <literal>' '</literal>. In each index
450 pair, the name and the type of the index is separated by a
451 colon character <literal>':'</literal>.
456 Any index name consisting of ASCII letters, and following the
457 standard &zebra; rules will do, see
458 <xref linkend="querymodel-pqf-apt-mapping-accesspoint"/>.
463 Index types are restricted to the values defined in
464 the standard configuration
465 file <filename>default.idx</filename>, see
466 <xref linkend="querymodel-bib1"/> and
467 <xref linkend="fields-and-charsets"/> for details.
472 &acro.dom; input documents which are not resulting in both one
474 <literal>record</literal> instruction and one or more valid
475 <literal>index</literal> instructions can not be searched and
477 invalid document processing is aborted, and any content of
478 the <literal><extract></literal> and
479 <literal><store></literal> pipelines is discarded.
480 A warning is issued in the logs.
486 <para>The examples work as follows:
487 From the original &acro.xml; file
488 <literal>marc-one.xml</literal> (or from the &acro.xml; record &acro.dom; of the
489 same form coming from an <literal><input></literal>
492 pipeline <literal><extract></literal>
493 produces an indexing &acro.xml; record, which is defined by
494 the <literal>record</literal> instruction
495 &zebra; uses the content of
496 <literal>z:id="11224466"</literal>
498 <literal>id=11224466</literal>
500 record ID, and - in case static ranking is set - the content of
501 <literal>rank=42</literal>
503 <literal>z:rank="42"</literal>
508 <para>In these examples, the following literal indexes are constructed:
516 where the indexing type is defined after the
517 literal <literal>':'</literal> character.
518 Any value from the standard configuration
519 file <filename>default.idx</filename> will do.
521 <literal>text()</literal> node content recursively contained
522 inside the <literal><z:index></literal> element, or any
523 element following a <literal>index</literal> processing instruction,
524 will be filtered through the
525 appropriate char map for character normalization, and will be
526 inserted in the named indexes.
529 Finally, this example configuration can be queried using &acro.pqf;
530 queries, either transported by &acro.z3950;, (here using a yaz-client)
533 Z> open localhost:9999
537 Z> find @attr 1=control @attr 4=3 11224466
538 Z> scan @attr 1=control @attr 4=3 ""
540 Z> find @attr 1=title program
541 Z> scan @attr 1=title ""
543 Z> find @attr 1=title @attr 4=2 "How to program a computer"
544 Z> scan @attr 1=title @attr 4=2 ""
548 extensions <literal>x-pquery</literal> and
549 <literal>x-pScanClause</literal> to
550 &acro.sru;, and &acro.srw;
553 http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=@attr 1=title program
554 http://localhost:9999/?version=1.1&operation=scan&x-pScanClause=@attr 1=title ""
557 See <xref linkend="zebrasrv-sru"/> for more information on &acro.sru;/&acro.srw;
558 configuration, and <xref linkend="gfs-config"/> or the &yaz;
559 <ulink url="&url.yaz.cql;">&acro.cql; section</ulink>
560 for the details or the &yaz; frontend server.
563 Notice that there are no <filename>*.abs</filename>,
564 <filename>*.est</filename>, <filename>*.map</filename>, or other &acro.grs1;
565 filter configuration files involves in this process, and that the
566 literal index names are used during search and retrieval.
569 In case that we want to support the usual
570 <literal>bib-1</literal> &acro.z3950; numeric access points, it is a
571 good idea to choose string index names defined in the default
572 configuration file <filename>tab/bib1.att</filename>, see
573 <xref linkend="attset-files"/>
582 <section id="record-model-domxml-conf">
583 <title>&acro.dom; Record Model Configuration</title>
586 <section id="record-model-domxml-index">
587 <title>&acro.dom; Indexing Configuration</title>
589 As mentioned above, there can be only one indexing pipeline,
590 and configuration of the indexing process is a synonym
591 of writing an &acro.xslt; stylesheet which produces &acro.xml; output containing the
592 magic processing instructions or elements discussed in
593 <xref linkend="record-model-domxml-canonical-index"/>.
594 Obviously, there are million of different ways to accomplish this
595 task, and some comments and code snippets are in order to
599 Stylesheets can be written in the <emphasis>pull</emphasis> or
600 the <emphasis>push</emphasis> style: <emphasis>pull</emphasis>
601 means that the output &acro.xml; structure is taken as starting point of
602 the internal structure of the &acro.xslt; stylesheet, and portions of
603 the input &acro.xml; are <emphasis>pulled</emphasis> out and inserted
604 into the right spots of the output &acro.xml; structure.
606 side, <emphasis>push</emphasis> &acro.xslt; stylesheets are recursively
607 calling their template definitions, a process which is commanded
608 by the input &acro.xml; structure, and is triggered to produce
609 some output &acro.xml;
610 whenever some special conditions in the input stylesheets are
611 met. The <emphasis>pull</emphasis> type is well-suited for input
612 &acro.xml; with strong and well-defined structure and semantics, like the
613 following &acro.oai; indexing example, whereas the
614 <emphasis>push</emphasis> type might be the only possible way to
615 sort out deeply recursive input &acro.xml; formats.
618 A <emphasis>pull</emphasis> stylesheet example used to index
619 &acro.oai; harvested records could use some of the following template
623 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
624 xmlns:z="http://indexdata.com/zebra-2.0"
625 xmlns:oai="http://www.openarchives.org/&acro.oai;/2.0/"
626 xmlns:oai_dc="http://www.openarchives.org/&acro.oai;/2.0/oai_dc/"
627 xmlns:dc="http://purl.org/dc/elements/1.1/"
630 <!-- Example pull and magic element style Zebra indexing -->
631 <xsl:output indent="yes" method="xml" version="1.0" encoding="UTF-8"/>
633 <!-- disable all default text node output -->
634 <xsl:template match="text()"/>
636 <!-- disable all default recursive element node transversal -->
637 <xsl:template match="node()"/>
639 <!-- match only on oai xml record root -->
640 <xsl:template match="/">
641 <z:record z:id="{normalize-space(oai:record/oai:header/oai:identifier)}">
642 <!-- you may use z:rank="{some XSLT; function here}" -->
644 <!-- explicetly calling defined templates -->
645 <xsl:apply-templates/>
649 <!-- OAI indexing templates -->
650 <xsl:template match="oai:record/oai:header/oai:identifier">
651 <z:index name="oai_identifier:0">
652 <xsl:value-of select="."/>
658 <!-- DC specific indexing templates -->
659 <xsl:template match="oai:record/oai:metadata/oai_dc:dc/dc:title">
660 <z:index name="dc_any:w dc_title:w dc_title:p dc_title:s ">
661 <xsl:value-of select="."/>
674 <section id="record-model-domxml-index-marc">
675 <title>&acro.dom; Indexing &acro.marcxml;</title>
677 The &acro.dom; filter allows indexing of both binary &acro.marc; records
678 and &acro.marcxml; records, depending on its configuration.
679 A typical &acro.marcxml; record might look like this:
682 <record xmlns="http://www.loc.gov/MARC21/slim">
684 <leader>00366nam 22001698a 4500</leader>
685 <controlfield tag="001"> 11224466 </controlfield>
686 <controlfield tag="003">DLC </controlfield>
687 <controlfield tag="005">00000000000000.0 </controlfield>
688 <controlfield tag="008">910710c19910701nju 00010 eng </controlfield>
689 <datafield tag="010" ind1=" " ind2=" ">
690 <subfield code="a"> 11224466 </subfield>
692 <datafield tag="040" ind1=" " ind2=" ">
693 <subfield code="a">DLC</subfield>
694 <subfield code="c">DLC</subfield>
696 <datafield tag="050" ind1="0" ind2="0">
697 <subfield code="a">123-xyz</subfield>
699 <datafield tag="100" ind1="1" ind2="0">
700 <subfield code="a">Jack Collins</subfield>
702 <datafield tag="245" ind1="1" ind2="0">
703 <subfield code="a">How to program a computer</subfield>
705 <datafield tag="260" ind1="1" ind2=" ">
706 <subfield code="a">Penguin</subfield>
708 <datafield tag="263" ind1=" " ind2=" ">
709 <subfield code="a">8710</subfield>
711 <datafield tag="300" ind1=" " ind2=" ">
712 <subfield code="a">p. cm.</subfield>
720 It is easily possible to make string manipulation in the &acro.dom;
721 filter. For example, if you want to drop some leading articles
722 in the indexing of sort fields, you might want to pick out the
723 &acro.marcxml; indicator attributes to chop of leading substrings. If
724 the above &acro.xml; example would have an indicator
725 <literal>ind2="8"</literal> in the title field
726 <literal>245</literal>, i.e.
729 <datafield tag="245" ind1="1" ind2="8">
730 <subfield code="a">How to program a computer</subfield>
734 one could write a template taking into account this information
735 to chop the first <literal>8</literal> characters from the
736 sorting index <literal>title:s</literal> like this:
739 <xsl:template match="m:datafield[@tag='245']">
740 <xsl:variable name="chop">
742 <xsl:when test="not(number(@ind2))">0</xsl:when>
743 <xsl:otherwise><xsl:value-of select="number(@ind2)"/></xsl:otherwise>
747 <z:index name="title:w title:p any:w">
748 <xsl:value-of select="m:subfield[@code='a']"/>
751 <z:index name="title:s">
752 <xsl:value-of select="substring(m:subfield[@code='a'], $chop)"/>
758 The output of the above &acro.marcxml; and &acro.xslt; excerpt would then be:
761 <z:index name="title:w title:p any:w">How to program a computer</z:index>
762 <z:index name="title:s">program a computer</z:index>
765 and the record would be sorted in the title index under 'P', not 'H'.
770 <section id="record-model-domxml-index-wizzard">
771 <title>&acro.dom; Indexing Wizardry</title>
773 The names and types of the indexes can be defined in the
774 indexing &acro.xslt; stylesheet <emphasis>dynamically according to
775 content in the original &acro.xml; records</emphasis>, which has
776 opportunities for great power and wizardry as well as grande
780 The following excerpt of a <emphasis>push</emphasis> stylesheet
781 <emphasis>might</emphasis>
782 be a good idea according to your strict control of the &acro.xml;
783 input format (due to rigorous checking against well-defined and
784 tight RelaxNG or &acro.xml; Schema's, for example):
787 <xsl:template name="element-name-indexes">
788 <z:index name="{name()}:w">
789 <xsl:value-of select="'1'"/>
794 This template creates indexes which have the name of the working
795 node of any input &acro.xml; file, and assigns a '1' to the index.
797 <literal>find @attr 1=xyz 1</literal>
798 finds all files which contain at least one
799 <literal>xyz</literal> &acro.xml; element. In case you can not control
800 which element names the input files contain, you might ask for
801 disaster and bad karma using this technique.
804 One variation over the theme <emphasis>dynamically created
805 indexes</emphasis> will definitely be unwise:
808 <!-- match on oai xml record root -->
809 <xsl:template match="/">
812 <!-- create dynamic index name from input content -->
813 <xsl:variable name="dynamic_content">
814 <xsl:value-of select="oai:record/oai:header/oai:identifier"/>
817 <!-- create zillions of indexes with unknown names -->
818 <z:index name="{$dynamic_content}:w">
819 <xsl:value-of select="oai:record/oai:metadata/oai_dc:dc"/>
826 Don't be tempted to play too smart tricks with the power of
827 &acro.xslt;, the above example will create zillions of
828 indexes with unpredictable names, resulting in severe &zebra;
833 <section id="record-model-domxml-debug">
834 <title>Debuggig &acro.dom; Filter Configurations</title>
836 It can be very hard to debug a &acro.dom; filter setup due to the many
837 successive &acro.marc; syntax translations, &acro.xml; stream splitting and
838 &acro.xslt; transformations involved. As an aid, you have always the
839 power of the <literal>-s</literal> command line switch to the
840 <literal>zebraidz</literal> indexing command at your hand:
842 zebraidx -s -c zebra.cfg update some_record_stream.xml
844 This command line simulates indexing and dumps a lot of debug
845 information in the logs, telling exactly which transformations
846 have been applied, how the documents look like after each
847 transformation, and which record ids and terms are send to the indexer.
852 <section id="record-model-domxml-elementset">
853 <title>&acro.dom; Exchange Formats</title>
855 An exchange format can be anything which can be the outcome of an
856 &acro.xslt; transformation, as far as the stylesheet is registered in
857 the main &acro.dom; &acro.xslt; filter configuration file, see
858 <xref linkend="record-model-domxml-filter"/>.
859 In principle anything that can be expressed in &acro.xml;, HTML, and
860 TEXT can be the output of a <literal>schema</literal> or
861 <literal>element set</literal> directive during search, as long as
862 the information comes from the
863 <emphasis>original input record &acro.xml; &acro.dom; tree</emphasis>
864 (and not the transformed and <emphasis>indexed</emphasis> &acro.xml;!!).
867 In addition, internal administrative information from the &zebra;
868 indexer can be accessed during record retrieval. The following
869 example is a summary of the possibilities:
872 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
873 xmlns:z="http://indexdata.com/zebra-2.0"
876 <!- - register internal zebra parameters - ->
877 <xsl:param name="id" select="''"/>
878 <xsl:param name="filename" select="''"/>
879 <xsl:param name="score" select="''"/>
880 <xsl:param name="schema" select="''"/>
882 <xsl:output indent="yes" method="xml" version="1.0" encoding="UTF-8"/>
884 <!- - use then for display of internal information - ->
885 <xsl:template match="/">
887 <id><xsl:value-of select="$id"/></id>
888 <filename><xsl:value-of select="$filename"/></filename>
889 <score><xsl:value-of select="$score"/></score>
890 <schema><xsl:value-of select="$schema"/></schema>
903 <section id="record-model-domxml-example">
904 <title>&acro.dom; Filter &acro.oai; Indexing Example</title>
906 The source code tarball contains a working &acro.dom; filter example in
907 the directory <filename>examples/dom-oai/</filename>, which
908 should get you started.
911 More example data can be harvested from any &acro.oai; compliant server,
912 see details at the &acro.oai;
913 <ulink url="http://www.openarchives.org/">
914 http://www.openarchives.org/</ulink> web site, and the community
916 <ulink url="http://www.openarchives.org/community/index.html">
917 http://www.openarchives.org/community/index.html</ulink>.
920 <ulink url="http://www.oaforum.org/tutorial/">
921 http://www.oaforum.org/tutorial/</ulink>.
933 <!-- Keep this comment at the end of the file
938 sgml-minimize-attributes:nil
939 sgml-always-quote-attributes:t
942 sgml-parent-document: "idzebra.xml"
943 sgml-local-catalogs: nil
944 sgml-namecase-general:t