Below is an example of a basic control file container, the actual content of which is explained later on in this chapter.
Example 2.2. Control file container
<?xml version="1.0"?> <!DOCTYPE profile> <profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns"> <!-- RESOURCES --> </profile>
The profile element (root node) contains one or more distinct resource elements. The permissible resource elements are specified in the schema files
A resource element either contains multiple and distinct property and resource elements or contains multiple instances of the same resource element or is empty. The permissible content of a resource element is specified in the schema files.
A property element is either empty or contains a literal value. The permissible property elements and values in each resource element are specified in the schema files
An element can be either a container of other elements (a resource) or have a literal value (a property), it can never be both. This restriction is specified in the schema files. A configuration component with more than one value must either be represented as some kind of embedded list in a property value or as a nested resource.
Nested resource elements allow a tree like structure of configuration components to be built to any level.
Example 2.3. Nested Resources
... <drive> <device>/dev/hda</device> <partitions config:type="list"> <partition> <size>1000mb</size> <mount>/</mount> </partition> <partition> <size>250mb</size> <mount>/tmp</mount> </partition> </partitions> </drive> ....
In the example above the disk resource consists of a device property and a partitions resource. The partitions resource contains multiple instances of the partition resource. Each partition resource contains a size and mount property.
Although it is specified in the schema files that the partitions resource contains multiple instances, it is still required to specify this to avoid wrong data typing in YaST2. Using the example above, imagine having a drive with only one partition. This will result in interpreting the partition resource as a property. To avoid this the following syntax must be used when defining multiple instances. For more information about type attributes, see next section.
Example 2.4. Nested Resources with type attributes
... <drive> <device>/dev/hda</device> <partitions config:type="list"> <partition> <size>1000</size> <mount>/</mount> </partition> <partition> <size>250</size> <mount>/tmp</mount> </partition> </partitions> </drive> ....
Global profile attributes are used to define meta-data on resources and properties. Attributes are used to define context switching. They are also used for naming and typing properties as shown in earlier sectionons [1].
Profile attributes are defined in the configuration namespace and must always be prefixed with config: . All profile attributes are optional. Most can be used with both resource and property elements but some can only be used with one type of element which is specified in the schema files.
The type of an element is defined using the config:type attribute. The type of a resource element is always RESOURCE , although this can also be made explicit with this attribute (to ensure correct identification of an empty element for example when there is no schema file to refer to). A resource element cannot be any other type and this restriction is specified in the schema file. The type of a property element determines the interpretation of its literal value. The type of a property element defaults to STRING , as specified in the schema file. The full set of permissible types is specified in the schema file.
[1] Profile attributes are in a separate namespace so they don't have to be treated as reserved words in the default namespace. New ones can then be added without having to potentially alter existing profiles.