All of the information about a service that is maintained by an SDP server is contained within a single service record. A service record consists entirely of a list of service attributes. To understand services and attributes, you should read [BS1 Service Discovery Protocol], but this page gives a few of the main points:
Each attribute has an ID, a type, and a value. The types, and some attribute IDs, are predefined: for example, the URL for the icon to show for a service must always have attribute ID value 12. Complex attributes can be formed through lists of attributes; such lists can themselves contain lists of attributes.
A key attribute is the service class (Bluetooth ID ServiceClassIDList): each service is an instance of a service class, which provides an initial indicator of the capabilities of the service, and defines what other attributes, including their types and semantics, must or can appear in the service record.
A single application may provide multiple services. These different services should have different service records. Additionally, each service record can have many service classes listed in it. These service classes must be in a subclasses/superclasses of each other, and must be ordered most derived to least derived in the list. For example, the service might have a class entry that indicates it provides printing services; and another class entry that indicates that it provides Postscript printing (and consequently has extra attributes relating to this).
In a service record, classes are specified using Universally Unique Identifier (UUID) numbers, values for which are predefined.
Note that the predefined values for class IDs and attribute IDs are in the appendix "Assigned Numbers" of [BS1]. Latest information can be found for Bluetooth SIG members from the Open group's web site http://www.opengroup.org/bluetooth.