2005 February
Table of Contents
This policy contains recommendations for the use of XML within KDE, as well as conventions for XML technologies part of KDE's public interfaces.
XML namespaces can be divided in two categories: namespaces for application specific XML formats, and namespaces for XML part of public interfaces.
By application specific namespaces is meant namespaces for XML formats which only applies for the usage scenario of a particular application. For example, an XML format used internally in an application or by 3rd party developers of that application.
This policy does not apply for application specific namespaces but leaves it to the developers in question.
By public namespaces is meant namespaces for XML formats which are part of KDE's cross-applications technologies, and are used by arbitrary applications. They are typically part of the kdelibs package.
All KDE's public namespaces must:
Be valid URIs, as per RFC 3986.
Start with http://www.kde.org/standards/, which is KDE's standardized namespace URI, followed by a name which distinguishes the namespace. After that resulting string, the string may be extended in an arbitrary way, while staying within the constraints of the URI syntax. For example, the namespace http://www.kde.org/standards/kcfg/2.0 as well as http://www.kde.org/standards/ktechnology/ are valid.
Table 1. Current Public Namespaces
| URI | Description |
|---|---|
| http://www.kde.org/standards/kcfg/1.0 | KConfigXT's *.kcfg files. |
The addition of new namespaces must be discussed on the mailinglist kde-core-devel@kde.org, and, if decided to be included, should result in this policy being updated to list the new namespace.
When in general designing W3C XML Schemas, these design principles should be kept in mind:
The name for type declarations should end with Type. For example:
<xsd:complexType name="containerType">
<!-- content -->
</xsd:complexType>
<xsd:element name="container" type="containerType" />
The design of the Schema should strive for having global type and element declarations, such that the Schema is flexible for future developments, for example inheritance and component reuse. In other words, the design should strive for being “flat”.
XML formats should be typed in W3C XML Schema or RELAX NG. The same XML format may in addition be expressed in other schema languages, such as DTD.