#######################################

Configuration ML Specification Document

#######################################

**Copyright (c) 2009 Nokia Corporation and/or its subsidiary(-ies).** All rights reserved. This component and the accompanying materials are made available under the terms of "Eclipse Public License v1.0" which accompanies this distribution, and is available at the URL "http://www.eclipse.org/legal/epl-v10.html".

==================

Table of contents:

==================

.. contents::

===================

1. Document Control

===================

1.1 References

--------------

#. Customization tool interoperability Requirements Specification

   http://www8.connecting.nokia.com/nmp/msw/tsw/series60/series60dm.nsf/WebAllByID/XXXJ16313-EN

#. XML Inclusions (XInclude) Version 1.0, W3C Recommendation, 20 December 2004

   http://www.w3.org/TR/xinclude/

#. Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation,

   http://www.w3.org/TR/2004/REC-xml-20040204

#. Modularization of XHTML, W3C Recommendation

   http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410

#. XML Linking Language (XLink) Version 1.0, W3C Recommendation, 27 June 2001

   http://www.w3.org/TR/xlink/

#. XML Path Language (XPath) Version 1.0, W3C Recommendation, 16 November 1999

   http://www.w3.org/TR/xpath

#. XML Schema Part 2: Datatypes Second Edition, W3C Recommendation, 28 October 2004

   http://www.w3.org/TR/xmlschema-2/

#. XHTML(TM) 2.0 - W3C Working Draft 22 July 2004

   http://www.w3.org/TR/xhtml2/

#. Extending and Versioning XML Languages with XML Schema

   http://www.pacificspirit.com/Authoring/Compatibility/ExtendingAndVersioningXMLLanguages.html

#. 

#. RELAX NG Specification, OASIS Committee Specification, 3 December 2001

   http://www.relaxng.org/spec-20011203.html

#. Uniform Resource Identifiers (URI): Generic Syntax, August 1998

   http://www.ietf.org/rfc/rfc2396.txt

#. S60 Customization Tool

   http://s60wiki.nokia.com/S60Wiki/S60_Customization_Tool

1.2 Glossary

------------

.. glossary::

   Central Repository

      `Symbian OS <http://s60wiki.nokia.com/S60Wiki/Symbian_OS>`_ service that provides a user interface to allow one or more clients to open repositories, and to provision and retrieve information from those repositories.

   Configuration

      Specific values for a collection of settings. Used to configure terminal SW for certain platform release, product or trade customer (for example operator). In Configuration ML the root element of the language and includes also feature and setting definitions.

   Configuration element

      Defines a `configuration <http://s60wiki.nokia.com/S60Wiki/S60_Terminal_SW_Configuration>`_  capability of software. Is used to define using one or more settings or features.

   Configuration enabler

      A software functionality that at runtime implements configurability for one or more setting

   Configuration Tool

      Tool used for configuring SW build (for example variant)

   ConfML

      Configuration Markup Language, language defined in this document

   Customization Tool

      S60 specific tool to configuring SW build (for example variant). Replaced by Configuration Tool. 

   Extension policy

      A mechanism for controlling how sequence item-settings for single setting in multiple configurations are handled.

   Feature

      A collection of related settings.

   Group

      For structuring settings in view.

   Item-setting

      A single item in a data of a sequence setting. Each item-setting defines values for sub-settings. For example, every contact in a data for phone book setting is an item-setting.

   lowerCamelCase

      Practice of writing `compound words <http://en.wikipedia.org/wiki/Compound_noun_and_adjective>`_ or phrases in which the words are joined without `spaces <http://en.wikipedia.org/wiki/Whitespace_%28computer_science%29>`_ and are `capitalized <http://en.wikipedia.org/wiki/Capitalization>`_ with the exception of the first word within the compound (http://en.wikipedia.org/wiki/CamelCase).

   Option

      Allowed value for a setting.

   Restore Factory Settings (RFS)

      Feature for reinitialising device data to factory settings stored on ROM.

   Setting

      Defines a single configurable element (for example mailbox name).

   Setting implementation

      Information about platform specific implementation. Used when building a configuration. Specific for the used configuration enabler

   Sub-configuration

      A configuration included in other configuration.

   Sub-setting

      Individual setting data elements that are available for each item-setting of a sequence data. For example, phone number field of every contact item-setting is a sub-setting.

   Value

      Defines a value of a setting. Single customizable value of a certain setting. For example Mailbox name.

   Variant 

      A specific kind of configuration. Term used in Customization Tool for customer specific values.

   View

      For rearranging settings into new structure and redefining their properties regardless how they where defined originally.

===============

2. Introduction

===============

2.1 Purpose and scope

---------------------

Configuration ML (later in document 'Configuration ML' or 'ConfML') is a XML-based markup language (that is, an XML application) for defining SW configuration elements and configuration data of SW product. 

Configuration ML is an evolution of XML language designed and used for S60 Customization Tool. Full compatibility with the tools already supporting so-called variant data files of earlier format was first seen as important. However, it was afterwards seen that compatibility would only make Configuration ML more complicated than needed. Also new features of such as mapping Boolean settings to bitmasks key in Central Repository and enabling incremental definition of sequences would have not been supported by old format. Therefore The Configuration ML is not compatible with variant features or variant data XML formats used by S60 Customization Tool. On the other hand it is possible to develop tools that support reading and/or writing both formats. Configuration ML language itself is not S60 specific and therefore can be used also outside S60.

2.2 Main concepts

-----------------

The Configuration ML consists of four plus one main components as shown in Figure 1.

.. image:: images/configurationml085-f1.gif 

Figure 1 The main components of Configuration ML

Configuration ML is primarily used to define configurations, features, settings, and data. The fourth component is Restore Factory Settings component, rfs. All these components are optional. Configuration is the top level concept of the language. It groups together relevant configuration features and values for them. Features consist of settings. Configurations are typically defined incrementally, and therefore configuration can be defined by means of any number of other configurations. Chapter 3 explains in detail the main concepts of the language.

Setting implementation definitions are defined using separate languages, which are defined in separate documents. One of the main goals of Configuration ML is to separate the logical feature definitions from the actual implementation specific details. Setting implementation definitions contain all the required logic to convert values in data part to implementation specific values that are used either at ROM image creation time or by the terminal software at runtime.

2.3 Applicability

-----------------

This specification defines how Configuration ML can be used to define all SW related configurability aspects of a software system. 

Configuration ML is most typically used for those local or global functionality and user experience related configuration elements that are used for localization, differentiation and customization purposes.

When defining configuration elements in using Configuration ML suitable abstraction level should be selected. In complex cases it might be better to use for example domain specific language and external file to describe the fine details, and only then have selection of an external file as a setting in Configuration ML. This approach also enables to build dedicated (possible graphical) tools to define the internal details of the element.

2.4 Namespace

-------------

All the elements of Configuration ML are defined in a single versioned namespace called http://www.s60.com/xml/confml/2 . The namespace is updated for major, possibly non-backward compatible versions only. New minor versions must maintain compatibility. The root element of the document, configuration, must contain an xmlns declaration for this namespace. None of the attributes in this specification belong to any namespaces and therefore are never prefixed.  

Example::

  <configuration xmlns="http://www.s60.com/xml/confml/2" />

When elements of Configuration ML are stored in a separately included file, namespace needs to be redefined. Refer to chapter 3.2.3 for more information on how to use multiple files to define a configuration.

The setting implementation information is defined in implementation specific namespace.  

The namespace of Configuration ML must not be used for any other elements than defined in this document. All extensions must be therefore defined in some other namespace.

2.5 MIME types and file name extensions

---------------------------------------

The MIME type for XML files of Configuration ML is 'text/application+xml'. 

It is recommended that all Configuration ML files use file name extension '.confml' (all lowercase) on all platforms.

The file name extensions of setting implementation XML files are implementation specific.

2.6 Reuse and Extensibility

---------------------------

Configuration ML relies heavily on other existing XML language. Following XML languages are used one way or another: XPATH [6], XInclude [2], and XML schema [7].

XPath is a language for addressing parts of an XML document. In support of this primary purpose, it also provides basic facilities for manipulation of strings, numbers, and Booleans. XPath uses a compact, non-XML syntax to facilitate use of XPath within URIs and XML attribute values. XPath operates on the abstract, logical structure of an XML document, rather than its surface syntax. Refer to chapter 3.4 and 3.3.2 for more information on XPath expressions are used in configuration ML.

XInclude is a standard for assembling XML instances into another XML document through inclusion. It enables larger documents to be dynamically created from smaller XML documents without having to physically duplicate the content of the smaller files in the main file. Refer to chapter 3.2.3 for more information on working with multiple files.

Configuration ML itself is designed to be extensible meaning that it can be further developed by defining new elements in own namespace.  

2.7 Validation and usage

------------------------

This document is the official definition for the Configuration ML XML language.

All Configuration ML documents must be valid XML 1.0 documents. The applications and tools supporting Configuration ML are assumed to check the well-formedness of the Configuration ML document instances.  

Every Configuration ML document should have XML declaration with version as the first thing in the file. 

The root element of every Configuration ML document must be configuration. The version attribute for this element must be specified as '1.0'.

Example::

  <?xml version="1.0"?>

    <configuration xmlns="http://www.s60.com/xml/confml/2" version="1.0">

    <!-- the body of the document -->

    </configuration>

2.8 Localization

----------------

As all XML documents, Configuration ML supports both UTF-8 and UTF-16 encodings. It is recommended to declare used encoding with XML declaration. This declaration is mandatory when other encoding than UTF-8 or UTF-16 is used. By default, UTF-8 encoding should be used, in case there is no good reason to do otherwise.  

Example::

  <?xml version="1.0" encoding="UTF-8"?>

  <!-- the rest of the document ->

Any characters from Unicode character set can be written in XML using XML Numerical Character Reference syntax: &#<decimal_character_code>; or &#x<hex_character_code>; .  

======================================================

3. Overview

======================================================

3.1 Components of Configuration ML

----------------------------------

Figure 2 depicts the main elements of Configuration ML language and how they map to implementation elements.

.. image:: images/configurationml085-f2.gif 

Figure 2 The main elements of Configuration ML

The elements shown in yellow are part of the Configuration ML. The elements shown in blue are implementation specific elements. For most of the Configuration ML elements shown in the Figure 2 there is a corresponding XML element. Those elements are defined in chapter 6. The elements named inside brackets represent either feature or setting specific XML elements as explained in chapter 3.4. The cardinalities of the elements are shown next to the connecting lines. The proximity of the cardinality marking defines the reading direction, for example "configuration can have any number of features".

3.2 Configuration

-----------------

Configuration is the top level concept in Configuration ML. Configuration has three main roles:

1. Defines configuration elements in terms of features and settings (chapter 3.3)

2. Defines views for visually rearranging settings (chapter 3.5)

3. Defines data (values) for settings (chapter 3.4)

Any configuration can have all the above rules or just one of them. Configuration can also just contain other configurations as explained in chapter 3.2.2.

3.2.1 Release specificity

^^^^^^^^^^^^^^^^^^^^^^^^^

Configuration ML is agnostic to versioning of software. Managing multiple versions of software component(s) that have varying configurability capabilities will typically require multiple (independent) Configuration ML documents. Release element of meta element can be used to identify the release of a software component, platform or product in question if required.

3.2.2 Hierarchical configurations

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Configurations are not typically defined in isolation, but they are parts of other configurations. To support this configuration can contain any number of other configurations (also called 'sub-configurations') as shown in the Figure 2. This enables features (including their settings), views, and data of a configuration to be defined using other configurations, which all can also be used independently of the including configurations when needed. The containment hierarchy of configurations would typically follow software or product architecture, or/and organisation developing the software or product.

For example when defined according to software architecture of a terminal product, there would be a 'master' configuration for the product itself that could include configurations of manufacturer specific platforms. These platform configurations could itself consist of configurations defining each architecture domain and eventually each subsystem and component in the platform. Each of these component configurations could define the relevant features, settings, and default values, while including configurations typically refine the values further.  

Each of the configurations can be created and used independently, in case they contain all the required includes so that referred setting definitions can be found. In addition they might override some or all the default values of the settings defined in included configurations.

Please note that only data (that is, setting values) of the contained configurations can be overridden but not views, features, or settings.

As a special case data of sequential settings can also be defined incrementally. In this case configuration extends (as a contrary to overriding) data of a setting that is defined in any of the included sub-configurations.

3.2.3 Structuring configurations to files

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Typically features need to created and maintained by several persons/organisation and therefore storing all feature definitions into one file would cause problems. The definitions of a configuration can be split to any number of XML files by using include elements of XInclude specification [2]. Therefore it is possible to have each of the sub-configurations in own files. The only constraints are that every included file itself must be a complete valid Configuration ML XML document (that is, with configuration as the root element). When using multiple Configuration ML files it is also important to make sure that every feature and setting is defined only once. Refining features or setting is not allowed except when using view definitions (see chapter 3.5).

When under single root configuration there exists multiple configurations with each own values, the priority of the values depends on the order: values later in XML document tree traversal order overrides any earlier values.

An example hierarchy of files is shown in Figure 3.

.. image:: images/configurationml085-f3.gif 

Figure 3 An example hierarchy of configuration files

In the example, there is two full configurations, one for product family and other for product variant (customised by operator). These configuration are composed by using includes. In a way, product family configuration is a subset of product variant configuration, and thus product variant could also include product family configuration and refine it further with product and variant specific definitions. However having each of the stakeholder represented as an a independent configuration, allows composing any kind of configuration more freely (e.g. free ordering, selecting only a subset). The order of inclusions defines also the override order, effectively acting as a method to define the inheritance order of configurations.

Only a subset of XInclude specification is required[1] to be supported with Configuration ML. First of all, support for inclusion of local resources with relative URI is required. All included resources are to be parsed as xml and therefore parse attribute is not required. Also, support for xi:fallback element is not required. Refer to chapter 4.5 for complete list of supported attributes of xi:include element.

.. [1] "Required" means here that some tools might choose to support more that what is required by this specification but must not assume the same from other tools.

3.3 Features and settings

-------------------------

3.3.1 Defining features and settings

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Each configuration defines zero or more configuration elements in terms of features and settings. A feature groups together related settings. One setting describes a certain configuration capability implemented in software. Every feature must be identified uniquely using ref attribute. Each feature must be unique and defined only once in configuration including any sub-configurations included in it. In the same way every setting must be uniquely identified inside a feature. Once feature or setting is defined, it cannot be anymore redefined or extended elsewhere in the configuration.  

3.3.2 Linking implementation to settings

----------------------------------------

Implementations of settings are defined in a separate file(s) as already shown in Figure 2. No implementation is defined on feature level but every setting can and should have its own implementation. Relative XPATH location path definitions are used to link the setting implementations to the settings. To create a location path that is unique in the configuration the ref path of the feature and setting is concatenated together.

3.4 Data

--------

3.4.1 Defining values

^^^^^^^^^^^^^^^^^^^^^

One of the main roles of configuration is to define values for settings. Values can be defined only for settings that have been declared in the configuration (including any sub-configurations). Although there can be only one data element containing the values in a configuration, all sub-configuration can also contain own data elements and therefore also values.

When values can be defined for settings in multiple places inside a configuration, it is important to understand the priority rules for interpreting them. One of the main use cases of Configuration ML is to allow overriding values of settings that were already defined in the included configuration. This is accomplished by utilizing normal xinclude expansion rules. In principle, include statements found from a configuration are expanded so that included document becomes a part of the including document. Prioritization of overrides is done by ordering the inclusions properly in the configuration.

Figure 4 shows example configuration hierarchy on top, and the processed (expanded) version on the bottom. In this example, value 3 is applied to setting A/B.

.. image:: images/configurationml085-f4.gif

Figure 4 Priority of values

As a special case, data of sequential settings can also be defined incrementally. In this case configuration can optionally extend (as a contrary to overriding) data of a setting that is defined in any of the included sub-configurations. This behaviour is controlled using extension policy of the setting data element (chapter 6.9). The extension can either append the new data to the end of existing data or prefix the existing data. If every configuration in the Figure 4 would contain value with append policy, then the actual data of that setting would be constructed in order of inclusions; first item(s) would be used from sub3.confml and the last items from the main configuration.

Most of the settings defined in configurations are meant to be configured on product or customer level. In order to allow defining the value of read-only attribute, values defined for settings that are defined directly in the same configuration do not need to obey read-onlyness statement of setting. Essentially this means that read-only settings can be modified locally in the defining configuration (which is usually in the same file as the setting definition), in other configurations (usually in other files) it is locked for modifications.

A configuration can directly define value at most only once of each setting.

3.4.2 Linking settings and values

---------------------------------

Values of a configuration are defined using element. Values can be defined for zero or more settings. Relative XPATH[6] paths are used to link values to settings on two levels: first on feature level and then on a setting level. See Figure 5 for illustration of how ref attributes are used.

.. image:: images/configurationml085-f5.gif 

Figure 5 Linking settings and values

Elements under data elements that do not match to any setting should be preserved during all processing but can be excluded from validation.

3.5 Views

---------

View definitions in configurations can be used to visually  rearrange selected features and settings into new structure regardless how they where defined originally. By default settings are clustered according to features they are defined in but with views this can be overridden by use of group elements. Support for hierarchical groups is not limited.

Any number of views can be defined in a configuration (including its sub-configurations) and it is up to tool or user of the tool to choose the active view if and when needed. Views are useful for creating for example terminal product specific views that show only the relevant settings and hide all the others. In addition to grouping selected features and settings, additional setting and option definitions can also be defined. This can be used for example to provide additional documentation for the user or to allow only restricted set of values to be defined. These additional definitions must never change the original meaning of the settings but can only restrict valid values even further from what was defined in the original setting definition. Therefore set of valid values according to the view must be a subset of valid values, as defined by the original setting definition. When validating data it is possible to use these additional restrictions in the active views also. As an example, if setting was originally defined to accept only values from 3 to 100, a view can add additional constraint that only allows odd numbers between 50 and 100. However, it would be illegal for view to define range from 2 to 110.

It is important to note that view only affects how the features, settings, and values are visualized and optionally validated. The view must not have any effect to meaning (including type and data reference) of it or existence of data, when using data for example for building a configuration. Therefore all constraints and dependencies in original setting definitions apply whether or not the features and/or settings are part of the active view.

================================

4. Common definition conventions

================================

This document defines Configuration ML language and its semantics. This section describes the conventions used in Configuration ML. These conventions are based on [4].

4.1 Structure

-------------

The language definition is structured in the following way:

- An abstract definition of the elements, attributes, and content models, as appropriate.

- A sub-section for each element; These sub-sections contain the following components:

 - A brief description of the element,

 - A definition of each attribute or attribute collection usable with the element, and

 - A detailed description of the behaviour of the element, if appropriate.

Examples are provided with most of the definitions. Please note that they typically only show the element and attribute relevant for the definition in question, and therefore should not be taken as complete Configuration ML examples. More complete examples are provided in implementation markup language specifications.

4.2 Syntactic Conventions

-------------------------

.. list-table::

   - - expr ?

     - Zero or one instances of expr are permitted.

   - - expr +

     - One or more instances of expr are required.

   - - expr *

     - Zero or more instances of expr are permitted.

   - - a ; b

     - Expression a and b are required in no specific order.

   - - a , b

     - Expression a is required, followed by expression b.

   - - a | b

     - Either expression a or expression b is required.

   - - a - b

     - Expression a is permitted, omitting elements in expression b.

   - - parentheses

     - n is contained within parentheses, evaluation of any sub-expressions within the parentheses take place before evaluation of expressions outside of the parentheses (starting at the deepest level of nesting first).

   - - defining required attributes

     - When an element requires the definition of an attribute, that attribute name is followed by an asterisk (*).

   - - defining the type of attribute values

     - When a module defines the type of an attribute value, it does so by listing the type in parentheses after the attribute name.

   - - defining the legal values of attributes

     - When the legal values are defined for an attribute, it does so by listing the explicit legal values (enclosed in quotation marks), separated by vertical bars (|), inside of parentheses following the attribute name. If the attribute has a default value, that value is followed by an asterisk (*). If the attribute has a fixed value, the attribute name is followed by an equals sign (=) and the fixed value enclosed in quotation marks.

4.3 Content Types

-----------------

Minimal, atomic content models are defined for each element. These minimal content models reference the elements in the language itself. They may also reference elements in other languages upon which the language depends. Finally, the content model in some cases requires that text be permitted as content to one or more elements. In these cases, the symbol used for text is PCDATA[3]. This is a term refers to processed character data. Content type can also be ANY, meaning that any elements can be supported. A content type can also be defined as EMPTY, meaning the element has no content in its minimal content model.

4.4 Attribute Types

-------------------

Following table lists definitions for all used XML attribute types. 

.. list-table::

   - - Attribute Types

     - Definition

   - - CDATA

     - Character data [3]

   - - IDREF

     - A reference to a document-unique identifier [3]

   - - NMTOKEN

     - A name composed of only name tokens as defined in XML 1.0 [3]. All leading and trailing whitespace is removed but no whitespace is allowed within the value itself.

   - - NMTOKENS

     - A whitespace separated list of NMTOKENs.

   - - NUMBER

     - Sequence consisting only digits ([0-9]) [3]

   - - URI

     - A Uniform Resource Identifier [12].

   - - XPATH (path)

     - An XPATH [6] location path. Support for only relative element location paths defined in abbreviated syntax is required. Only subset of XPATH language is supported; refer to examples for details.

   - - 

     - 

   - - xs:token

     - Whitespace-replaced and collapsed strings as defined in XML Schema [7]. In addition to removing all leading and trailing whitespace, also all consecutive spaces, carriage returns, linefeeds and tabs within the value itself are replaced by a single space.

4.5 Naming conventions

----------------------

Element, attribute, and type names are composed of words in the English language, using the British English spellings.

Lower Camel Case (LCC) is used for naming attributes, elements, and types. Lower Camel Case capitalizes the first character of each word except the first word and compounds the name.

=====================

5. Common definitions

=====================

This chapter contains common attribute and element definitions used by elements in Configuration ML and setting implementation languages.

.. list-table::

   - - Elements

     - Attributes

     - Content Model

   - - `elements supporting CommonAttrs <#_Common_attributes_(CommonAttrs)>`_

     - id (NMTOKEN)

     - N/A

   - - `meta <#_Meta_elements>`_

     - CommonAttrs

     - id?; date?; owner?; editor?; status?; version?; platform?; product?; release?; customer?; origin?; target?; desc?; icon?; link*

   - - `desc <#_The_desc_element>`_

     - CommonAttrs, xl:href (URI), xl:title (CDATA)

     - PCDATA

   - - `icon <#_The_icon_element>`_

     - CommonAttrs, xl:href* (URI), xl:title (CDATA)

     - EMPTY

   - - `link <#_The_link_element>`_

     - CommonAttrs, xl:href* (URI), xl:title (CDATA)

     - EMPTY

   - - xi:include

     - CommonAttrs, href* (URI)

     - EMPTY

Elements starting with xi namespace prefix are defined in XInclude[2]. Only listed attributes are supported for those elements. The rest of the elements are defined in the following sections.

5.1 Common attributes (CommonAttrs)

-----------------------------------

The CommonAttrs attribute collection defines common attributes used by all Configuration ML elements. These attributes don't belong to any namespace and therefore must not be prefixed. These attributes are optional always.

.. list-table::

   - - Attributes name

     - Type

     - Default

     - Description

   - - id

     - NMTOKEN

     - not defined

     -  The identifier of an element. Not used within language for identification. If defined ) the id of an element must be unique within the user interface definition. Typically descriptive ids that describe the purpose of the element should be used.

Example::

  <feature id="myfeatureid">

   <setting id="thesetting"/>

  </feature>

5.2 Meta elements

-----------------

The meta elements define common metadata for certain elements in configuration and setting implementation documents. The meta element is the parent for all other meta elements. Typically meta element is the first child of the root element. None of the meta elements have any attributes but all the content is defined as PCDATA.

In addition to common elements the following meta specific elements are defined in this specification.

.. list-table::

   - - Elements

     - Attributes

     - Content Model

   - - id

     - CommonAttrs

     - PCDATA

   - - date

     - CommonAttrs

     - PCDATA in the format CCYY-MM-DD\[z\|\(-\|+\)hh\:mm\]

   - - owner

     - CommonAttrs

     - PCDATA

   - - editor

     - CommonAttrs

     - PCDATA

   - - status

     - CommonAttrs

     - PCDATA

   - - version

     - CommonAttrs

     - PCDATA

   - - platform

     - CommonAttrs

     - PCDATA

   - - product

     - CommonAttrs

     - PCDATA

   - - release

     - CommonAttrs

     - PCDATA

   - - customer

     - CommonAttrs

     - PCDATA

   - - origin

     - CommonAttrs

     - PCDATA

   - - target

     - CommonAttrs

     - PCDATA

The date is defined according to data type 'date' of XML Schema [7]. UTC time zone can be defined with letter Z at the end of the date string. Other time zones are represented by their difference from UTC in the format +hh:mm or -hh:mm. If no time zone is defined then it is undefined. Meta element can be extended by defining new child elements in a separate namespace.

Example::

  <configuration>

   <meta>

    <date>2006-06-19</date>

    <owner>John Smith</owner>

    <editor>John smith Junior</editor>

    <status>draft</status>

    <platform>S60</platform>

    <product>N99</product>

    <release>3.9</release>

    <desc>Reference configuration</desc>

    <customer>MegaOperator</customer>

   </meta>

  </configuration>

5.3 The desc element

--------------------

The desc element can be used for description or documentation for any element. The data can be defined either as the content of the element or using xl:href attribute.

.. list-table::

   - - Attributes name

     - Type

     - Default