The GILS profile is only concerned with the communication that takes place between two compliant systems. It doesn't mandate how the client application should behave, and it doesn't tell you how you should maintain and process data at the server side. Specifically, while the profile specifies a number of different exchange format for retrieval records.
For the purposes of this discussion, we will be using a simple, SGML-like representation of the GILS record structure. There is nothing magical or sacrosanct about this format, but it is easy to read and write, and because of its semblance of SGML and HTML, it is familiar to many people. If you would like to use a different, local representation for your GILS records, you can read the general Zebra documentation to learn how to establish a custom input filter for your particular record format.
In the SGML-like syntax, each record should begin with the tag
<gils>
. This selects the GILS profile, and provides context
for the content tags which follow. Similarly, each record should
finish with the end-tag <
gils>/.
The body of the record is made up by a sequence of tagged elements,
reflecting the abstract record syntax of the GILS profile. Some
of these elements contain simple data, or text, while others contain
more tagged elements - these are complex, or constructed, data
elements. The tag names generally correspond to the tag names provided
in the GILS profile. Capitalization is ignored in tag names, as are
dashes (-). Hence, local-subject-index
is equivalent to
LocalSubjectIndex
which is the same as LOCALSUBJECTINDEX
.
It is useful to look at the records in the test/records
as
examples of how SGML-formatted GILS record can look. Note that
whitespace is generally ignored, so you can choose whatever layout of
your records that suits you best.