<article>
<title>Specifying and Using Application (Database) Profiles
<author>Index Data, <tt/info@index.ping.dk/
-<date>$Revision: 1.2 $
+<date>$Revision: 1.5 $
<abstract>
YAZ includes a subsystem to manage complex database records, driven
by a set of configuration tables that reflect a given profile.
the same database. The record management system is responsible for
associating a given record with a specific profile, and processing it
accordingly. This document describes the various file formats for data
-and configuration files which are understood by the module.
+and configuration files which are used by the module.
</abstract>
<toc>
<item>The exact workings of the subsystem may depend on the
application in which it is used. This document focuses on the use of
-the module in the <bf/ZServer/ system which is distributed by Index
-Data as a companion to <bf/YAZ/.
+the module in the <bf/Zebra/ information server which is distributed by Index
+Data as an independent package.
</itemize>
<sect>Introduction
that the data won't look like this when it's transmitted from the
server to the client, however. Typically, the client will prefer to
receive the data in a more rigid syntax, such as USMARC or GRS-1. To
-save transmissiontime and avoid ambiguities of language, the
+save transmission time and avoid ambiguities of language, the
individual tags or field names, above, might be translated into
numbers which are known by both the client and the server (by
referring to a tag set).
this, it needs a set of configuration files to describe the
application profile that the given record adheres to.
+<it>
+CAUTION: Because the tables described below serve the dual purpose of
+representing an external application profile and an internal database
+profile, the terminology and structuring used will sometimes be
+somewhat different from the one suggested in the the Z39.50-1995.
+</it>
+
<sect1>The Abstract Syntax
<p>
known.
<item>The variant set which is used in the profile. This provides a
-vocabulary for specifying the <it/types/ of data that appear inside
+vocabulary for specifying the <it/forms/ of data that appear inside
the records.
<item>Element set names, which are a shorthand way for the client to
<tag>type <it/integer type-name datatype/</tag> (repeatable) Addes a
new type to the current class (the one introduced by the most recent
-<bf/class/ directive. The type names belong to the same name space as
+<bf/class/ directive). The type names belong to the same name space as
the one used in the tag set definition file.
</descrip>
occurrences-specification (see below). The tag-value can be a number
or a string. If the first character is an apostrophe ('), this forces
the value to be interpreted as a string, even if it appears to be numerical.
+
<item>A WildThing, represented as a question mark (?), possibly
followed by a colon (:) followed by an occurrences specification (see
below).
+
<item>A WildPath, represented as an asterisk (*). Note that the last
-element of the path should not be a wildPath.
+element of the path should not be a wildPath (wildpaths don't work in
+this version).
</itemize>
The occurrences-specification can be either the string <tt/all/, the
<sect1>The Schema Mapping (.map) Files
<p>
-Sometimes, the client might want wish to receive a database record in
+Sometimes, the client might want to receive a database record in
a schema that differs from the native schema of the record. For
instance, a client might only know how to process WAIS records, while
the database record is represented in a more specific schema, such as
to actually converting the data to the ISO2709). This use of the
object identifier for USMARC as a schema identifier represents an
overloading of the OID which might not be entirely proper. However,
-it represents the dual role of schema identifier/record syntax which
+it represents the dual role of schema and record syntax which
is assumed by the MARC family in Z39.50.
<it>
<it>NOTE: This will be described better.</it>
+<sect>The Input (Data) File Format
+
+<p>
+The retrieval module is designed to manage data derived from a
+variety of different input sources. When used on the client side, the
+source format may be GRS-1 ISO2709. On the server side, the source may
+be a structured ASCII file, augmented by a set of patterns that
+describe the structure of the document.
+
+What we think of as the native source format - the one that is
+guaranteed to provide complete access to the facilities of the module,
+is an &dquot;SGML-like&dquot; syntax, based on an inferred DTD, which
+is in turn based on the profile information from the various files
+mentioned in this document.
+
+Like SGML, an input record consists of tags and data. The tags are
+enclosed by brackets (<...>). As a general rule, each tag should
+be matched by a corresponding close tag, identified by the same tag
+name preceded by a slash (/).
+
<sect>License
<p>
Copyright © 1995, Index Data.
+This is the Index Data &dquot;P&dquot; license - it applies exclusively to
+the record management module of the YAZ system, and to this
+document.
+
Permission to use, copy, modify, distribute, and sell this software and
its documentation, in whole or in part, for any purpose, is hereby granted,
provided that:
projects / yaz-moved-to-github.git / blobdiff