This documentation provides instructions on how to use the Project Endings staticSearch Generator to provide a fully-functional search ‘engine’ to your website without any dependency on server-side code such as a database.
The generator tool processes your site to create an index of all the words appearing in the site, stemmed (if desired) using a stemmer, and stores the index in the form of a large number of small JSON files. It also creates JSON files for other search facets that you specify in the headers of your documents, to allow searches for documents by type, by date range, and so on. Then it creates a search page for your site, which processes user search terms and retrieves the required JSON files to provide search results.
You can see several examples of sites and projects which use staticSearch in Projects using staticSearch.
Digital Humanities projects such as digital editions of historical and literary texts are typically the work of teams of people collaborating over many years, and the fruit of their labours deserves to have a significant shelf-life, if possible comparable with that of a traditional print publication. However, digital longevity of DH projects is sadly short, and many disappear or cease to function within a few years of their creation, because of their dependency on transient tools and technologies.
However, static websites (websites which consist entirely of HTML, CSS and JavaScript, without any dependency on back-end server systems such as databases or PHP processing) are far more resilient in the long term than sites which use more server-side technology, and are also much easier to archive and replicate (see Holmes and Takeda (2019), The Prefabricated Website: Who needs a server anyway?). For this reason, the Project Endings team have been developing and publicizing strategies for moving digital projects to an all-static publication model. The most problematic component in the all-static approach is search.
Most digital publications take one of two approaches to search: either they have their own back-end database search engine (perhaps Solr or an XML database), or they rely on commercial services such as Google (which may be free, but are still beyond the control of the project team). DH projects need sophisticated options for searching, but typically this requires the use of technologies that may become obsolete or unsupported, or services which may change their terms of use or become unavailable.
staticSearch solves this problem. It provides the capability to build a sophisticated faceted search engine into your website without the need for any back-end services at all (except of course for a web server, which you need anyway).
The Generator supports the following features:
+
(plus) before a word means that search results must contain that word, and adding a -
(minus) means that results must not contain that word. Words without plus or minus are treated as may contain, contributing to the score of any retrieved document.lo[uv]e?
to find ‘loved’, ‘loued’, ‘loves’, ‘louer’, etc. If you don't have a stemmer for the language of your document collection, this
feature is a good alternative (although it can be combined with a stemmer as well
for greater flexibility).The Generator supports the following search facets:
There are two ways to get the staticSearch code. The first is to download a release package from the project release page; we recommend that you get the latest version. You can download a zip file and unzip it to create a folder containing the code.
The second way to get the codebase is to clone it from the GitHub repository. If you're doing this, you can clone either the current master branch, the last release tag, or the dev branch. If you clone the dev branch, bear in mind that you're working with development code and things may break.
First, you will have to make sure your site pages are correctly configured so that the Generator can parse them. Then, you will have to create a configuration file specifying what options you want to use. Then you run the generator, and the search functionality should be added to your site.
The generator is expecting to parse well-formed XHTML5 web pages. That means web pages which are well-formed XML, using the XHTML namespace. If your site is just raggedy tag-soup, then you can't use this tool. You can tidy up your HTML using HTML Tidy.
Next, you will need to decide whether you want search filters or not. If you want to allow your users to search (for example) only in poems, or only in articles, or only in blog posts, or any combination of these document types, you will need to add <meta> tags to the heads of your documents to specify what these filters are. staticSearch supports four filter types.
The configuration file is an XML document which tells the Generator where to find your site, and what search features you would like to include. The configuration file conforms to a schema which is documented here.
There are three main sections of the configuration file:
Only the <params> element is necessary, but, as we discuss shortly, we highly suggest taking advantage of the <rules> and <contexts> for the best results.
The <params> element has two required elements for determining the resource collection that you wish to index:
The <searchFile> element is a relative URI (resolved, like all URIs specified in the config file, against the configuration file location) that points directly to the search page that will be the primary access point for the search. Since the search file must be at the root of the directory that you wish to index (i.e. the directory that contains all of the XHTML you want the search to index), the searchFile parameter provides the necessary information for knowing what document collection to index and where to put the output JSON. In other words, in specifying the location of your search page, you are also specifying the location of your document collection. See Creating a search page for more information on how to configure this file.
Note that all output files will be in a directory that is a sibling to the search page. For instance, in a document collection that looks something like:
The collection of Javascript and JSON files will be in a directory like so:
We also require the <recurse> element in the case where the document collection may be nested (as is common with static sites generated from Jekyll or Wordpress). The <recurse> element is a boolean (true or false) that determines whether or not to recurse into the subdirectories of the collection and index those files.
The following parameters are optional, but most projects will want to specify some of them:
The staticSearch project currently has only one real stemmer, an implementation of the Porter 2 algorithm for modern English. That appears in /stemmers/en/, so the default value for this parameter is en. We will be adding more stemmers as the project develops. However, if your document collection is not English, you have a couple of options, one hard and one easy.
Another alternative is the stripDiacritics stemmer. Like the identity stemmer, this is not really a stemmer at all; what it does is to strip out all combining diacritics from tokens. This is a useful approach if you document collection contains texts with accents and diacritics, but your users may be unfamiliar with the use of diacritics and will want to search just with plain unaccented characters. For example, if a text contains the word élève, but you would like searchers to be able to find the word simply by typing the ascii string eleve, then this is a good option. Combined with wildcards, it can provide a very flexible and user-friendly search engine in the absence of a sophisticated stemmer, or for cases where there are mixed languages so a single stemmer will not do. To use this option, specify the value stripDiacritics in your configuration file.
The value of the match attribute is transformed in a XSLT template match attribute, and thus must follow
the same rules (i.e. no complex rules like p/ancestor::div
). See the W3C XSLT Specification for further details on allowable pattern rules.
Note that the indexer does not tokenize any content in the <head> of the document (but as noted above, metadata can be configured into filters) and that all elements in the <body> of a document are considered tokenizable. However, common elements that you might want to exclude include:
"...the size of the index.Search filtering using any metadata you like,..."
"...nothing to say here,Some information on this subject can be found...
To tell the tokenizer that the <span> constitutes the context block for any of its token, use the <context> element with an match pattern:
The default contexts elements are:
A complex site may have two or more search pages targetting specific types of document or content, each of which may need its own particular search controls and indexes. This can easily be achieved by specifying a different <searchFile> and <outputFolder> in the configuration file for each search.
However, it's also likely that you will want to exclude certain features or documents from a specialized search page, and this is done using the <excludes> section and its child <exclude> elements.
Using exclusions, you can create multiple specialized search pages which have customized form controls within the same document collection. This is at the expense of additional disk space and build time, of course; each of these searches needs to be built separately.
Note that once your file has been processed and all this content has been added, you can process it again at any time; there is no need to start every time with a clean, empty version of the search page.
You can take a look at the test/search.html page for an example of how to configure the search page (although note that since this page has already been processed, it has the CSS and the search controls embedded in it; it also has some additional JavaScript which we use for testing the search build results, which is not necessary for your site).
Once you have configured your HTML and your configuration file, you're ready to create a search index and a search page for your site. This requires that you run ant in the root folder of the staticSearch project that you have downloaded or cloned.
Note: you will need Java and Apache Ant installed, as well as ant-contrib.
Before running the search on your own site, you can test that your system is able to do the build by doing the (very quick) build of the test materials. If you simply run the ant command, like this:
mholmes@linuxbox:~/Documents/staticSearch$ ant
you should see a build process proceed using the small test collection of documents, and at the end, a results page should open up giving you a report on what was done. If this fails, then you'll need to troubleshoot the problem based on any error messages you see. (Do you have Java, Ant and ant-contrib installed and working on your system?).
If the test succeeds, you can view the results by uploading the test folder and all its contents to a web server, or by running a local webserver on your machine in that folder, using the Python HTTP server or PHP's built-in web server.
If the tests all work, then you're ready to build a search for your own site. Now you need to run the same command, but this time, tell the build process where to find your custom configuration file:
ant -DconfigFile=/home/mholmes/mysite/config_staticSearch.xml
The same process should run, and if it's successful, you should have a modified search.html page as well as a lot of index files in JSON format in your site HTML folder. Now you can test your own search in the same ways suggested above.
The tokenizing process first processes your configuration file to create an XSLT file with all your settings embedded in it. Next, it processes your document collection using those settings. Each document is tokenized, and then a separate JSON file is created for each distinct token found; this file contains links to each of the documents which contain that token, as well as keyword-in-context strings for the actual tokens. There will most likely be thousands of these files, but most of them are quite small. These constitute the textual index.
In addition, separate JSON files are created for the list of document titles, and for your stopword list if you have specified one. A single text file is also created containing all the unique terms in the collection, used when doing wildcard searches.
Next, if you have specified search facets in your document headers, the processor will then create a separate JSON file for each of those search facets, consisting of a list of the document identifiers for all documents which match the filters; so if some of your documents are specified as ‘Illustrated’ and some not (true or false), a JSON file will be created for the ‘Illustrated’ facet, with a list of documents which are true for this facet, and a list of documents which are false.
Finally, the template file you have created for the search page on your site will be processed to add the required search controls and JavaScript to make the search work.
In order to provide fast, responsive search results, the search page must download only the information it needs for each specific search. Obviously, if it were to download the entire collection of thousands of token files, the process would take forever. So when you search for the word waiting, what happens is that the JavaScript stems that word, producing wait, then it downloads only the single file containing indexing information for that specific word, which is very rapid. (If you are using a different stemmer, of course, then the token will be stemmed to a different output. If you are using the identity stemmer, then the token will be unchanged; with the stripDiacritics pseudo-stemmer, all combining diacritics will be stripped from the search terms, as they are in the corresponding index.)
However, there is some information that is required for all or many searches. To display any results, the list of document titles must be downloaded, for example. A user may for instance use the search facets only, not searching for a particular word or phrase but just wanting a list of all the documents classified as ‘Poems’. This requires that the JSON file with information about that facet be downloaded. So there is some advantage in having the JavaScript start downloading some of the essential files (titles, stopwords and so on) as soon as the page loads, and it also starts downloading the facet files in the background.
At the same time, though, we don't want to clog up the connection downloading these files when the user may do a simple text search which doesn't depend on them, so these files are retrieved using a ‘trickle’ approach, one at a time. Then if a search is initiated, all the files required for that specific search can be downloaded as fast as possible overriding the trickle sequence for files that are needed immediately.
Once the user has been on the search page for any length of time, all ancillary files will have been retrieved (assuming they weren't already cached by the browser), so the only files required for any search are those for the actual text search terms; the response should therefore be even faster for later searches than for early ones.
Below are some of the most common things you might want to do using staticSearch:
How do I get staticSearch to ignore large chunks of my document? | Any element with a weight of 0 is ignored completely by the indexer, so add a <rule> for the element. So to ignore all elements with the class ignoreThisElement, you could do something like:
<rule weight="0"
match="div[contains-token(@class,'ignoreThisElement')"/> |
How do I get staticSearch to ignore small inline bits and not have them in the KWIC? | As above, you can use a <rule> with an weight=0 |
How do I get staticSearch to ignore an element, but retain its text in the KWIC? | Here, you'll want to use the <exclude> function, which excludes the element from indexing, but doesn't remove it from the
document itself. So, if you wanted to exclude all keyboard entry items (<xh:kbd>), but still have them in the KWIC, you could do something like:
<exclude match="kbd"
type="index"/> |
How can I get staticSearch to show debugging messages? | Switch <verbose> to true in the configuration file:
<config xmlns="http://hcmc.uvic.ca/ns/staticSearch">
<params> <!--....--> <verbose>true</verbose> <!--....--> </params> <!--Rules, etc--> </config> |
How can I get staticSearch to jump straight to a specific hit in the document from a search result? | The best way to do this is to ensure that <linkToFragmentId> is set to the true and that the input HTML contains ids at whatever level you think is most helpful. For instance, if possible, you could give each <xhtml:p> element an id, which would mean that each KWIC could be linked to the right paragraph in the input document. |
New features and enhancements:
Bug fixes:
Name | Search Page(s) | Configuration file(s) |
The Map of Early Modern London | Search | SVN |
The Winnifred Eaton Archive | Search | Github |
Mapping Keat's Progress | Search | SVN |
My Norse Digital Image Repository | Search | SVN |
The Colonial Despatches of BC and Vancouver Island | Search | SVN |
The Scandinavian-Canadian Studies Journal | Search | SVN |
The Robert Graves Diary | Search | SVN |
Digital Victorian Periodical Poetry | Search (multiple searches with individual pages) | SVN (multiple configuration files) |
<config> (The root element for the Search Generator configuration file.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
—
|
May contain | |
Content model |
<content> <elementRef key="params"/> <elementRef key="rules" minOccurs="0"/> <elementRef key="contexts" minOccurs="0"/> <elementRef key="excludes" minOccurs="0"/> </content> |
Schema Declaration |
element config { params, rules?, contexts?, excludes? } |
<context> (A context definition, providing a match attribute that identifies the context, allowing keyword-in-context fragments to be bounded by a specific context.) | |||||||
Namespace | http://hcmc.uvic.ca/ns/staticSearch | ||||||
Module | ss — Schema specification and tag documentation | ||||||
Attributes | att.match (@match) att.labelled (@label)
|
||||||
Contained by |
ss: contexts
|
||||||
May contain | Empty element | ||||||
Content model |
<content> <empty/> </content> |
||||||
Schema Declaration |
element context { att.match.attributes, att.labelled.attributes, attribute context { text }?, empty } |
<contexts> (The set of contexts, expressed as XPath in match, that controls the identification of contexts for keyword-in-context fragments.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: config
|
May contain |
ss: context
|
Content model |
<content> <elementRef key="context" minOccurs="1" maxOccurs="unbounded"/> </content> |
Schema Declaration |
element contexts { context+ } |
<createContexts> (Whether to include keyword-in-context extracts in the index. This increases the size of the index considerably, but it allows for more user-friendly search results, as well as phrasal searches.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD boolean
|
Content model |
<content> <dataRef name="boolean"/> </content> |
Schema Declaration |
element createContexts { xsd:boolean } |
<dictionaryFile> (The location of a dictionary file (one word per line) which will be used to check tokens when indexing.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD anyURI
|
Content model |
<content> <dataRef name="anyURI"/> </content> |
Schema Declaration |
element dictionaryFile { xsd:anyURI } |
<exclude> (An exclusion definition, which excludes either documents or filters as defined by an XPath in match.) | |||||||
Namespace | http://hcmc.uvic.ca/ns/staticSearch | ||||||
Module | ss — Schema specification and tag documentation | ||||||
Attributes | att.match (@match)
|
||||||
Contained by |
ss: excludes
|
||||||
May contain | Empty element | ||||||
Content model |
<content> <empty/> </content> |
||||||
Schema Declaration |
element exclude { att.match.attributes, attribute type { "index" | "filter" }, empty } |
<excludes> (The set of exclusions, expressed as XPath in match, that control the subset of documents for a particular search.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: config
|
May contain |
ss: exclude
|
Content model |
<content> <elementRef key="exclude" minOccurs="1" maxOccurs="unbounded"/> </content> |
Schema Declaration |
element excludes { exclude+ } |
<indentJSON> (Whether or not to indent code in the JSON index files. Indenting increases the file size, but it can be useful if you need to read the files for debugging purposes.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD boolean
|
Content model |
<content> <dataRef name="boolean"/> </content> |
Schema Declaration |
element indentJSON { xsd:boolean } |
<kwicTruncateString> (The string that will be used to signal ellipsis at the beginning and end of a keyword-in-context extract. Conventionally three periods, or an ellipsis character.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain | Character data only |
Content model |
<content> <textNode/> </content> |
Schema Declaration |
element kwicTruncateString { text } |
<linkToFragmentId> (Whether to link keyword-in-context extracts to the nearest id in the document. Default is true.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD boolean
|
Content model |
<content> <dataRef name="boolean"/> </content> |
Schema Declaration |
element linkToFragmentId { xsd:boolean } |
<maxKwicsToHarvest> (This controls the maximum number of keyword-in-context extracts that will be stored for each term. If phrasalSearch is set to true, this parameter is ignored, because phrasal searches will only work properly if all contexts are stored.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD nonNegativeInteger
|
Content model |
<content> <dataRef name="nonNegativeInteger"/> </content> |
Schema Declaration |
element maxKwicsToHarvest { xsd:nonNegativeInteger } |
<maxKwicsToShow> (This controls the maximum number of keyword-in-context extracts that will be shown in the search page for each hit document returned.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD nonNegativeInteger
|
Content model |
<content> <dataRef name="nonNegativeInteger"/> </content> |
Schema Declaration |
element maxKwicsToShow { xsd:nonNegativeInteger } |
<outputFolder> (The name of the output folder into which the index data and JavaScript will be placed in the site search. This should conform with the XML Name specification.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD NCName
|
Content model |
<content> <dataRef name="NCName"/> </content> |
Schema Declaration |
element outputFolder { xsd:NCName } |
<params> (Element containing most of the settings which enable the Generator to find the target website content and process it appropriately.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: config
|
May contain | |
Content model |
<content> <elementRef key="searchFile"/> <elementRef key="versionFile" minOccurs="0"/> <elementRef key="stemmerFolder" minOccurs="0"/> <elementRef key="recurse"/> <elementRef key="linkToFragmentId" minOccurs="0"/> <elementRef key="scrollToTextFragment" minOccurs="0"/> <elementRef key="scoringAlgorithm" minOccurs="0"/> <elementRef key="phrasalSearch" minOccurs="0"/> <elementRef key="wildcardSearch" minOccurs="0"/> <elementRef key="createContexts" minOccurs="0"/> <elementRef key="maxKwicsToHarvest" minOccurs="0"/> <elementRef key="maxKwicsToShow" minOccurs="0"/> <elementRef key="totalKwicLength" minOccurs="0"/> <elementRef key="kwicTruncateString" minOccurs="0"/> <elementRef key="verbose" minOccurs="0"/> <elementRef key="stopwordsFile" minOccurs="0"/> <elementRef key="dictionaryFile" minOccurs="0"/> <elementRef key="replacementsFile" minOccurs="0"/> <elementRef key="indentJSON" minOccurs="0"/> <elementRef key="outputFolder" minOccurs="0"/> </content> |
Schema Declaration |
element params { } |
<phrasalSearch> (Whether or not to support phrasal searches. If this is true, then the maxContexts setting will be ignored, because all contexts are required to properly support phrasal search.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD boolean
|
Content model |
<content> <dataRef name="boolean"/> </content> |
Schema Declaration |
element phrasalSearch { xsd:boolean } |
<recurse> (Whether to recurse into subdirectories of the collection directory or not.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD boolean
|
Content model |
<content> <dataRef name="boolean"/> </content> |
Schema Declaration |
element recurse { xsd:boolean } |
<rule> (A rule that specifies a document path as XPath in match, and provides weighting for search terms found in that context.) | |||||||
Namespace | http://hcmc.uvic.ca/ns/staticSearch | ||||||
Module | ss — Schema specification and tag documentation | ||||||
Attributes | att.match (@match)
|
||||||
Contained by |
ss: rules
|
||||||
May contain | Empty element | ||||||
Content model |
<content> <empty/> </content> |
||||||
Schema Declaration |
element rule { att.match.attributes, attribute weight { text }, empty } |
<rules> (The set of rules, expressed as XPath in match, that control weighting of search terms found in specific contexts.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: config
|
May contain |
ss: rule
|
Content model |
<content> <elementRef key="rule" minOccurs="1" maxOccurs="unbounded"/> </content> |
Schema Declaration |
element rules { rule+ } |
<scoringAlgorithm> (Which scoring algorithm to use. Default is "raw" (i.e. weighted counts)) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain | Empty element |
Content model |
<content> <valList type="closed"> <valItem ident="raw"> <desc>raw score</desc> <gloss>Default: Calculate the score based off of the weighted number of instances of a term in a text.</gloss> </valItem> <valItem ident="tf-idf"> <gloss>Calculate the score based off of the tf-idf scoring algorithm.</gloss> </valItem> </valList> </content>Legal values are:
|
Schema Declaration |
element scoringAlgorithm { "raw" | "tf-idf" }Legal values are:
|
<scrollToTextFragment> (WARNING: Experimental technology. This turns on a feature currently only supported by a subset of browsers, enabling links from keyword-in-context results directly to the specific text string in the target document.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD boolean
|
Content model |
<content> <dataRef name="boolean"/> </content> |
Schema Declaration |
element scrollToTextFragment { xsd:boolean } |
<searchFile> (The search file (aka page) that will be the primary access point for the staticSearch. Note that this page must be at the root of the collection directory.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD anyURI
|
Content model |
<content> <dataRef name="anyURI"/> </content> |
Schema Declaration |
element searchFile { xsd:anyURI } |
<stemmerFolder> (The name of a folder inside the staticSearch /stemmers/ folder, in which the JavaScript and XSLT implementations of stemmers can be found. If left blank, then the staticSearch default English stemmer will be used (stemmers/en).) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD NCName
|
Content model |
<content> <dataRef name="NCName"/> </content> |
Schema Declaration |
element stemmerFolder { xsd:NCName } |
<stopwordsFile> (The location of a text file containing a list of stopwords (words to be ignored when indexing). These are typically words too common to be worth searching for, but every site will also have some specific terms which are used so widely across the site that they should be suppressed to control the index size. The list should be in plain text with one word per line.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD anyURI
|
Content model |
<content> <dataRef name="anyURI"/> </content> |
Schema Declaration |
element stopwordsFile { xsd:anyURI } |
<totalKwicLength> (If createContexts is set to true, then this parameter controls how long the contexts will be.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD nonNegativeInteger
|
Content model |
<content> <dataRef name="nonNegativeInteger"/> </content> |
Schema Declaration |
element totalKwicLength { xsd:nonNegativeInteger } |
<verbose> (Turns on more detailed reporting during the indexing process.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD boolean
|
Content model |
<content> <dataRef name="boolean"/> </content> |
Schema Declaration |
element verbose { xsd:boolean } |
<versionFile> (The relative path to a text file containing a single version identifier (such as 1.5, 123456, or 06ad419). This will be used to create unique filenames for JSON resources, so that when a site is updated, so that the browser will not use cached versions of older index files.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD anyURI
|
Content model |
<content> <dataRef name="anyURI"/> </content> |
Schema Declaration |
element versionFile { xsd:anyURI } |
<wildcardSearch> (Whether or not to support wildcard searches. Note that wildcard searches are more effective when phrasal searching is also turned on, because the contexts available for phrasal searches are also used to provide wildcard results.) | |
Namespace | http://hcmc.uvic.ca/ns/staticSearch |
Module | ss — Schema specification and tag documentation |
Contained by |
ss: params
|
May contain |
XSD boolean
|
Content model |
<content> <dataRef name="boolean"/> </content> |
Schema Declaration |
element wildcardSearch { xsd:boolean } |
att.labelled (A class providing a label attribute that can be used to identify/describe contexts and other things which benefit from description.) | |||||||
Module | ss — Schema specification and tag documentation | ||||||
Members | context | ||||||
Attributes |
|
att.match (A class providing attributes that enable specification of document locations.) | |||||||
Module | ss — Schema specification and tag documentation | ||||||
Members | context exclude rule | ||||||
Attributes |
|