From: Sebastian Hammer Date: Wed, 6 Dec 1995 09:49:13 +0000 (+0000) Subject: Work. X-Git-Tag: YAZ.1.8~856 X-Git-Url: http://git.indexdata.com/?p=yaz-moved-to-github.git;a=commitdiff_plain;h=1b9f6e078470e18513ac273c3e3e089b214c2d81 Work. --- diff --git a/doc/profiles.sgml b/doc/profiles.sgml index 6497cdf..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.4 $ +<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. @@ -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> @@ -581,7 +591,7 @@ 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. -The native source format - the one that is +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 @@ -592,69 +602,15 @@ 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 (/). -The first tag in the file represents the root of the record. It should -contain the name of the application profile that the record belongs -to. If the profile is not already known, the system will look for the -profile description in the file <tt/profile.abs/, where <tt/profile/ -is the name of the given profile. - -The following is a typical beginning of a GILS record: - -<tscreen><verb> -<gils> - <Title> - USGS server for Gopher. See available linkage to begin. - <Acronym> - USGS Gopher - &etago;Acronym> - &etago;Title> - - ... - -&etago;gils> -</verb></tscreen> - -<it> -NOTE: The indentation of the elements shows above is applied solely -to clarify the relationships between the elements. Any unnecessary -whitespaces are ignored by the retrieval system. -</it> - -The construction above describes the first element of a GILS record; -the title. The title is structured into a &dquot;well-known&dquot; -element, and an additional element with a local string tag, -<bf/Acronym/. Since the -tag <bf/Title/ appears in tagsetG, which is included by the GILS -tagset, this is a well-known element. The tag <bf/Acronym/ appears -nowhere in the tagsets for the GILS profile, so it is treated as a -locally defined string tag by the system. - -<sect1>Types of Input Elements - -<p> -Currently, X types of input elements are recognized: - -<itemize> -<item>The root element, which associates the record with a given -schema. - -<item>The normal tagged element, which corresponds either to a -specific tag from the tag sets referenced by the schema, or to a -locally defined string tag (implicitly). - -<item>An inclusion element, for inserting data from an external source -(a file, typically) into the record. - -<item>An element data unit, which corresponds to normal data. - -<item>A variant-component. -</itemize> - <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: