X-Git-Url: http://git.indexdata.com/?p=yaz-moved-to-github.git;a=blobdiff_plain;f=doc%2Fprofiles.sgml;h=675d83096040b4be282cf8ec8392d67dfab799c6;hp=5c8220fde061ef1f44259c3d441d56ce8b6b5289;hb=30cfc59b71c25923e2e9cfb63c310c095bb3b6c1;hpb=2927cf8d4c742fee3978ca41b3ade18b3af1fd60 diff --git a/doc/profiles.sgml b/doc/profiles.sgml index 5c8220f..675d830 100644 --- a/doc/profiles.sgml +++ b/doc/profiles.sgml @@ -2,7 +2,7 @@
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. @@ -10,7 +10,7 @@ Multiple database profiles can coexeist in the same server, or even 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> @@ -25,8 +25,8 @@ may change as the module matures. <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 @@ -115,7 +115,7 @@ Depending on the database profile that is being used, it is likely 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). @@ -125,6 +125,13 @@ be carried out by the server based on requests from the client. To do 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> @@ -147,7 +154,7 @@ mapping the tags to their numerical representation, if they are 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 @@ -423,7 +430,7 @@ class to the variant set. <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> @@ -493,11 +500,14 @@ parenthesis, possibly followed by a colon (:) followed by an 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 @@ -528,7 +538,7 @@ simpleelement (4,52) <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 @@ -538,7 +548,7 @@ record into fields consistent with the given MARC specification, prior 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> @@ -572,11 +582,35 @@ header of the record. <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: