<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "AppStream.ent">
%BOOK_ENTITIES;
]>

<section id="sect-AppStream-ASXML">
	<title>AppStream distribution XML files</title>

	<section id="spec-asxml-introduction">
		<title>Introduction</title>

		<para>
			AppStream XML files are small textfiles describing all available applications in the distribution's package repositories.
			The XML files might be compressed with GZip.
		</para>
	</section>

	<section id="spec-asxml-filenaming">
		<title>File naming and location</title>
		<para>
			The XML files must have an unique name, which is usually the distribution's name and version, combined with the name of the repository/origin.
			For example in Debian 8 (Jessie), the filename for the main repository component would be <filename>debian-jessie-main.xml.gz</filename>.
			For Fedora 20 (Heisenbug) updates it would be <filename>fedora-20-updates.xml.gz</filename>.
			3rd-party repositories use a vendor name and repository-name combination, for example Ubuntu PPAs might get <filename>ppa-ubuntu12.04-username-foobar.xml</filename>.
		</para>
		<para>
			There are two valid locations to store AppStream XML data. <filename>/usr/share/app-info/xmls</filename> stores all AppStream data which
			has been installed via software packages, while <filename>/var/cache/app-info/xmls</filename> stores application data which was downloaded
			by the package manager or placed there by other tools (e.g. Limba).
			The XML files can either be plain files or be compressed with gzip. It is always a good idea to compress the files, because they tend to become
			quite large.
		</para>
	</section>

	<section id="spec-asxml-general">
		<title>General XML structure</title>
		<para>
			The XML starts with an <code>&lt;components&gt;</code> tag as root element. It has all the
			<code>&lt;component&gt;</code> tags of different <literal>type</literal> as children.
		</para>
		<para>
			Data to fill the different component elements is usually taken from their <ulink url="http://standards.freedesktop.org/desktop-entry-spec/latest/">Desktop files</ulink>
			and package data. However, if an upstream project ships metainfo files (see <xref linkend="chap-Metadata"/>),
			values defined there should override data from any other source.
		</para>
		<para>
			All child elements of the <code>&lt;components&gt;</code> element, no matter of which type they are, must at least have
			an <literal>id</literal>, <literal>name</literal>, <literal>summary</literal> and <literal>pkgname</literal> tag.
			For applications, a <literal>icon</literal> tag is also required.
		</para>
		<para>
			The <code>&lt;components&gt;</code> root node has these properties, where the first two are required:
		</para>
		<variablelist>
			<varlistentry>
			<term>version</term>
			<listitem>
				<para>
					This property declares the AppStream spec version this file is based on (currently 0.6). The property is required.
				</para>
			</listitem>
			</varlistentry>

			<varlistentry>
			<term>origin</term>
			<listitem>
				<para>
					Defines the repository-id this AppStream XML file belongs to. This usually matches the filename without extension (see the explanation on how to pick a good filename above).
					It is also used to associate the right cached icons with AppStream metadata. This property is required.
				</para>
			</listitem>
			</varlistentry>
		</variablelist>
	</section>

	<section id="spec-asxml-tags">
		<title>Valid tags for all component types</title>
		<para>
			These tags can be applied to every component type (application, component, font, inputmethod) which
			is described in the AppStream metadata.
		</para>
		<para>
			Additionally to the <literal>type</literal> property, every <literal>&lt;component/&gt;</literal> tag in AppStream distro data
			may have a <literal>priority</literal> property, defining the priority of this specific metadata over other metadata from different
			AppStream XML files (e.g. from a different repository) which have the same component-id. The value of this tag is an integer, if the
			property is missing, a value of <code>"0"</code> is assumed.
		</para>

		<variablelist>
			<varlistentry id="tag-distro-component-id">
			<term>&lt;id/&gt;</term>
			<listitem>
				<para>
					The <code>&lt;id/&gt;</code> tag is a short unique and usually lower-cases identifier for the component.
					Depending on the component's type, different naming conventions apply.
				</para>
			</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-pkgname">
				<term>&lt;pkgname/&gt;</term>
				<listitem>
					<para>
						The name of the package which needs to be installed in order to make this component available on the system.
					</para>
					<para>
						This tag can be defined multiple times, if a component is split across multiple packages.
					</para>
					<important>
						<para>
							The preferred way is to create metapackages containing the component metadata, and referncing them
							from the distribution metadata, and not to use multiple <literal>pkgname</literal> tags.
							They should only be used multiple times as a workaround or if there is no sensible way of creating a
							matching metapackage.
						</para>
					</important>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-source_pkgname">
				<term>&lt;source_pkgname/&gt;</term>
				<listitem>
					<para>
						This optional tag is used to specify the source package the binary package this component belongs to was built from.
					</para>
					<para>
						The tag can be used by software center applications to group components. It is otherwise useful for the distributor
						to assign components to a source package and to fetch additional information about a package from the web.
					</para>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-name">
				<term>&lt;name/&gt;</term>
				<listitem>
					<para>
						A human-readable name for this component.
					</para>
					<para>
						In case of a component of type <literal>desktop</literal>, the application name as defined in the application's
						<ulink url="http://standards.freedesktop.org/desktop-entry-spec/latest/">desktop file</ulink> is used.
					</para>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-project_license">
				<term>&lt;project_license/&gt;</term>
				<listitem>
					<para>
						The <code>&lt;project_license/&gt;</code> tag is indicating the license of the component.
						It should be a string in SPDX format. Licenses may be combined using <emphasis>and</emphasis> and <emphasis>or</emphasis> logic.
						Possible values include:
						<itemizedlist>
							<listitem><para>GPL-2.0</para></listitem>
							<listitem><para>LGPL-3.0+ and GPL-3.0+</para></listitem>
							<listitem><para>MIT</para></listitem>
							<listitem><para>CC-BY-SA-2.0</para></listitem>
							<listitem><para>...</para></listitem>
						</itemizedlist>
						A full list of recognized licenses and their identifiers can be found at the
						<ulink url="http://spdx.org/licenses/">SPDX OpenSource License Registry</ulink>.
					</para>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-summary">
				<term>&lt;summary/&gt;</term>
				<listitem>
					<para>
						The tag contains a short summary of the purpose and function of this component. In case the component is of
						type <literal>desktop</literal>, it is usually taken from a Desktop file,
						if the application does not ship an upstream metadata file.
					</para>
					<para>
						For more information about this tag, take a look at the tag's definition at <xref linkend="tag-summary"/>.
					</para>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-description">
				<term>&lt;description/&gt;</term>
				<listitem>
					<para>
						A long description of the component. It is usually taken from the package descriptions or meta-info files, if they were provided.
						The description might use markup. Right now, only paragraph, ordered list and unordered list are supported.
						An example description element might look like this:
						<programlisting language="XML"><![CDATA[<description>
  <p>
   Power Statistics is a program used to view historical and current battery
   information and will show programs running on your computer using power.
  </p>
  <p>Example list:</p>
  <ul>
   <li>First item</li>
   <li>Second item</li>
  </ul>
  <p>
  You probably only need to install this application if you are having problems
  with your laptop battery, or are trying to work out what programs are using
  significant amounts of power.
  </p>
 </description>]]></programlisting>
					</para>
					<para>
						As opposed to the by-paragraph translation used in meta-info files, this tag is translated "as a whole", meaning that the
						<literal>&lt;description/&gt;</literal> tag itself has a language property and contain the translated paragraphs for the given language.
						This allows faster parsing of the Appstream XML file, and does not increase it's size much, as long as it is compressed.
					</para>
					<para>
						For more information about this tag, take a look at the tag's definition at <xref linkend="tag-description"/>.
					</para>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-url">
				<term>&lt;url/&gt;</term>
				<listitem>
					<para>
						Defines URLs for this component. This tag can be present multiple times.
					</para>
					<para>
						For a list of possible url types and what they are expected to do,
						take a look at the tag's description at <xref linkend="tag-url"/>.
					</para>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-project_group">
				<term>&lt;project_group/&gt;</term>
				<listitem>
					<para>
						The <code><![CDATA[<project_group>]]></code> tag identifies a project with a specific upstream umbrella project.
						Known values include <literal>GNOME, KDE, XFCE, LXDE, Mozilla</literal> and <literal>MATE</literal>, although other umbrella projects
						like <literal>Yorba</literal> would make sense too.
					</para>
					<note>
						<para>
							Components should only identify with an umbrella project if you use all their infrastructure and policies, for instance
							string freezes dates, bugtracker and source control instance.
						</para>
					</note>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-icon">
				<term>&lt;icon/&gt;</term>
				<listitem>
					<para>
						The <code>&lt;icon/&gt;</code> tag describes the component icon. It is mostly used for GUI applications (component-type <literal>desktop</literal>).
						It can be of the type <literal>stock</literal>, <literal>cached</literal>, <literal>local</literal>,
						or <literal>url</literal>.
					</para>
					<para>
						<literal>stock</literal> icons are loaded from stock. The icon name should never include any file-extension or path.
					</para>
					<para>
						<literal>cached</literal> icons are loaded from the AppStream icon cache. The icon tag should contain the icon file name, including it's
						extension. It must not contain a full or relative path to the icon file.
					</para>
					<para>
						<literal>local</literal> icons are reserved for AppStream data installed by local applications or via 3rd-party application installers.
						They should specify a full file path.
						This icon type may have <literal>width</literal> and <literal>height</literal> properties.
					</para>
					<para>
						<literal>remote</literal> icons loaded from a remote URL. Currently, at least HTTP urls must be supported.
						This icon type may have <literal>width</literal> and <literal>height</literal> properties.
					</para>
					<para>
						Examples of the different methods to specify an icon:
					</para>
					<programlisting language="XML"><![CDATA[<icon type="stock">gimp</icon>
<icon type="cached">firefox.png</icon>
<icon type="remote" width="64" height="64">http://example.com/icons/foobar.png</icon>
<icon type="local" width="64" height="64">/usr/share/pixmaps/foobar.png</icon>]]></programlisting>
					<para>
						Multiple <code><![CDATA[<icon/>]]></code> tags might be combined for one application, e.g. to define a <literal>stock</literal> icon
						and a <literal>cached</literal> icon.
						Software-Centers should always prefer the stock icon, if it is available, and fall back to the other icon types if they can not find it.
						The <emphasis>libappstream</emphasis> library makes it easy to do that, if you are not accessing the Xapian database manually.
					</para>
					<para>
						The AppStream Xapian database generator will prefer <literal>cached</literal> over <literal>local</literal> over <literal>remote</literal>
						icons when setting the non-stock icon for the application.
					</para>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-mimetypes">
				<term>&lt;mimetypes/&gt;</term>
				<listitem>
					<para>
						This tag can contain one or more <code><![CDATA[<mimetype>]]></code> tags, describing the mime types this component supports.
						The data can usually be fetched from the Desktop files.
						Example:
					</para>
					<programlisting language="XML"><![CDATA[<mimetypes>
    <mimetype>text/html</mimetype>
    <mimetype>image/jpeg</mimetype>
    <mimetype>application/rss+xml</mimetype>
 </mimetypes>]]></programlisting>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-categories">
				<term>&lt;categories/&gt;</term>
				<listitem>
					<para>
						This tag can contain one or more <code><![CDATA[<category>]]></code> tags, describing the categories this application
						is located in. This tag is usually applied to components of type <literal>desktop</literal>, although it might be used by others later.
						This data is usually taken from Desktop files, a list of categories can be found in the
						<ulink url="http://standards.freedesktop.org/menu-spec/latest/apa.html">Freedesktop menu spec</ulink>.
						Example:
					</para>
					<programlisting language="XML"><![CDATA[<categories>
    <category>GNOME</category>
    <category>GTK</category>
    <category>Network</category>
    <category>Telephony</category>
</categories>]]></programlisting>
					<note>
						<title>Deprecated Tags</title>
						<para>
							The tag <code><![CDATA[<appcategories>]]></code> with its <code><![CDATA[<appcategory>]]></code> child elements is deprecated API.
							AppStream parsers should handle these tags just like the <literal>category</literal> tags, there is no difference except for the name.
						</para>
					</note>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-keywords">
				<term>&lt;keywords/&gt;</term>
				<listitem>
					<para>
						This tag can contain one or more <code><![CDATA[<keyword>]]></code> tags, describing keywords for the component,
						to make it easier to find in a software center.
						In case of type <literal>desktop</literal> components, this data is taken from Desktop files. For <literal>addon</literal>
						components, the upstream metadata file usually provides this tag.
						Example:
					</para>
					<programlisting language="XML"><![CDATA[<keywords>
  <keyword>IDE</keyword>
  <keyword>development</keyword>
  <keyword>programming</keyword>
</keywords>]]></programlisting>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-screenshots">
				<term>&lt;screenshots/&gt;</term>
				<listitem>
					<para>
						This tag can contain one or more <code><![CDATA[<screenshot>]]></code> tags, describing screenshots which are available for
						the application. A screenshot tag my have the attribute <code>type="default"</code>, marking it as the application's default screenshot,
						which primarily represents it in a software center.
					</para>
					<para>
						Every <code><![CDATA[<screenshot>]]></code> is defined by several images of different sizes.
						All images should have their width and hight set as arguments. Also, one of the images should be marked as <code>type="source"</code>,
						indicating that it is the unscaled version of the screenshot.
						Images of <code>type="thumbnail"</code> define thumbnails of the screenshot.
					</para>
					<para>
						The metadata generator should scale the source image down to several thumbnails useful for the client to load.
						The recommended sizes for thumbnail images are:
					</para>
					<itemizedlist>
						<listitem><para><emphasis>752x423</emphasis> (large)</para></listitem>
						<listitem><para><emphasis>624x351</emphasis> (normal)</para></listitem>
						<listitem><para><emphasis>112x63</emphasis> (small)</para></listitem>

						<listitem><para><emphasis>1504x846</emphasis> (large, HiDPI)</para></listitem>
						<listitem><para><emphasis>1248x702</emphasis> (normal, HiDPI)</para></listitem>
						<listitem><para><emphasis>224x126</emphasis> (small, HiDPI)</para></listitem>
					</itemizedlist>
					<para>
						In order to support HiDPI screens, the thumbnails should also be available in their bigger sizes. A metadata generator should, however, never attempt
						to scale up a smaller image to a larger size, and just ship the smaller sizes instead.
					</para>
					<para>
						Optionally, a screenshot can contain a <code><![CDATA[<caption>]]></code> tag, describing the screenshot's caption. This is usually what the user can see
						on the image shown. The tag is translatable.
					</para>
					<para>
						Every image should have a full remote url set, usually pointing to a cache of images maintained by the distributor.
						Example:
					</para>
					<programlisting language="XML"><![CDATA[<screenshots>
  <screenshot type="default">
    <caption>Foobar showing kitchen-sink functionality</caption>
    <caption xml:lang="si">Foobar shoeewing kischän-sünk funzionality</caption>
    <image type="source" width="800" height="600">http://www.example.org/en_US/main.png</image>
    <image type="thumbnail" width="752" height="423">http://www.example.org/en_US/main-large.png</image>
    <image type="thumbnail" width="112" height="63">http://www.example.org/en_US/main-small.png</image>
  </screenshot>
  <screenshot>
     ....
  </screenshot>
</screenshots>]]></programlisting>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-compulsory_for_desktop">
				<term>&lt;compulsory_for_desktop/&gt;</term>
				<listitem>
					<para>
						The <code><![CDATA[<compulsory_for_desktop>]]></code> tag indicates that the component which the metadata belongs to is essential for the
						functionality of the defined desktop environment. Examples for compulsory components are the <literal>GNOME-Shell</literal> by the GNOME-Project,
						or the <literal>Plasma-Desktop</literal> by KDE, as well as things like <literal>iBus</literal> or the desktop login manager.
					</para>
					<para>
						Software centers are expected to detect the running desktop environment and disable uninstallation for compulsory components of that desktop,
						so users will not be able to damage their currently running, primary desktop environment.
					</para>
					<para>
						Multiple occurrences of the <code><![CDATA[<compulsory_for_desktop>]]></code> tag are allowed, so a project can be essential for many desktops.
						The distributor decides which components should be made compulsory, however it is generally a good idea to follow upstream's recommendations on that matter.
					</para>
					<para>
						A list of all allowed values for this tag is defined in the <ulink url="http://standards.freedesktop.org/menu-spec/latest/apb.html">XDG Menu Specification</ulink>.
						Software center applications will only recognize these values.
					</para>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-provides">
				<term>&lt;provides/&gt;</term>
				<listitem>
					<para>
						This tag is described in detail at <xref linkend="sect-Metadata-GenericComponent"/>.
					</para>
					<para>
						For generic component types, this tag has to be present.
						Distributors must ensure that all things described in this tag are present in the package referenced in
						the associated <literal>pkgname</literal> tag.
					</para>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-developer_name">
			<term>&lt;developer_name/&gt;</term>
			<listitem>
				<para>
					The <code>&lt;developer_name/&gt;</code> tag as described in the specification for a generic component. See <xref linkend="tag-developer_name"/> for more information.
				</para>
			</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-releases">
				<term>&lt;releases/&gt;</term>
				<listitem>
					<para>
						The <literal>releases</literal> tag and its <literal>release</literal> children are structured as described in <xref linkend="tag-releases"/>.
					</para>
					<para>
						Each <literal>release</literal> tag may have a <literal>description</literal> tag as child, containing a brief description of what is new in the release.
						The <literal>description</literal> tag is structured as described in <xref linkend="tag-distro-description"/>. This also applies to its translation rules.
					</para>
					<para>
						The AppStream distro XML generator may shorten overlong lists of releases to a smaller list, e.g. of 4 <literal>release</literal> tags.
						It may also convert ISO 8601 <literal>date</literal> properties of the metainfo file into an UNIX timestamp <literal>timestamp</literal> property.
						It should avoid generating metadata containing both properties on a <literal>release</literal> tag.
					</para>
					<para>
						Example for a valid releases tag:
					</para>
					<programlisting language="XML"><![CDATA[<releases>
  <release version="1.8" timestamp="1424116753">
    <description>
      <p>This stable release fixes the following bug:</p>
      <ul>
        <li>CPU no longer overheats when you hold down spacebar</li>
      </ul>
    </description>
    <size type="download">12345678</size>
    <size type="installed">42424242</size>
  </release>
  <release version="1.2" timestamp="1397253600" />
  <release version="1.0" timestamp="1345932000" />
</releases>]]></programlisting>
					<para>
						In case a <code>&lt;release/&gt;</code> tag has a <code>&lt;description/&gt;</code> tag as parameter, describing the new release briefly, distributors are encouraged to provide 2-4
						<code>&lt;release/&gt;</code> release tags for every component. If no description is provided, one tag is enough.
					</para>
					<para>
						Components of type <literal>firmware</literal> (<xref linkend="sect-Metadata-Firmware"/>) may also have a <xref linkend="tag-firmware-location"/> tag as child of one of the
						<code>&lt;release/&gt;</code> tags. In case a <code>&lt;location/&gt;</code> tag is present, it must be accompanied by a <code>&lt;checksum/&gt;</code> tag, containing
						a checksum of the downloaded file. This is done to ensure the integrity of the downloaded firmware, and that the user gets the firmware which was tested by the distributor.
						The <code>&lt;location/&gt;</code> tag is often used in case the distributor is not allowed to legally redistribute the firmware in a native package.
					</para>
					<para>
						The <code>&lt;checksum/&gt;</code> tag has a <code>type</code> attribute, describing the checksumming-algorithm that was used to create it. Currently, only <literal>SHA1</literal>
						is supported.
					</para>
					<para>
						Example for a <code>&lt;release/&gt;</code> tag of a firmware component which makes use of <code>&lt;location/&gt;</code>:
					</para>
					<programlisting language="XML"><![CDATA[<release version="2.0.3" timestamp="1429362707">
  <location>http://www.hughski.com/downloads/colorhug2/firmware/colorhug2-2.0.3.cab</location>
  <checksum type="sha1">40b59e37cb918f3241f65bc5ac2b90ab47b34e8c</checksum>
  <description>
    <p>This stable release fixes problems.</p>
  </description>
</release>]]></programlisting>
				</listitem>
			</varlistentry>


			<varlistentry id="tag-distro-architectures">
				<term>&lt;architectures/&gt;</term>
				<listitem>
					<para>
						If the <literal>architectures</literal> tag is present, the component is not available on all architectures the distribution supports.
						Supported architectures for this component are specified as children using the <literal>arch</literal> tag.
					</para>
					<para>
						For example, this marks a component to only be available on i686:
					</para>
					<programlisting language="XML"><![CDATA[<architectures>
  <arch>i686</arch>
</architectures>]]></programlisting>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-languages">
				<term>&lt;languages/&gt;</term>
				<listitem>
					<para>
						This tag gives information about the translations a component provides, and to which extent the software is translated.
					</para>
					<para>
						The tag is allowed to only occur once per component, and contains multiple <code>&lt;lang/&gt;</code> child nodes, which have
						a <ulink url="https://www.gnu.org/software/gettext/manual/html_node/Language-Codes.html">language code</ulink> as value.
						Each <code>&lt;lang/&gt;</code> node may have a <literal>percentage</literal> property, which describes the percentage value to which
						a component has been translated.
					</para>
					<para>
						The language data is expected to be extracted by the AppStream XML generator, and is not provided upstream. Generators may obtain the
						information from processing GNU Gettext files, which should cover most translation methods.
					</para>
					<para>
						Tag example:
					</para>
					<programlisting language="XML"><![CDATA[<languages>
  <lang percentage="96">gu</lang>
  <lang percentage="94">ca@valencia</lang>
  <lang percentage="91">de</lang>
  <lang percentage="93">eo</lang>
</languages>
]]></programlisting>
				</listitem>
			</varlistentry>

			<varlistentry id="tag-distro-bundle">
				<term>&lt;bundle/&gt;</term>
				<listitem>
					<para>
						The optional <literal>bundle</literal> tag indicates that the described software is available as a software bundle via a
						3rd-party application installer. The value of this tag is an identification string for the bundle.
					</para>
					<para>
						Software centers may use the information of this tag to offer the user to install the software
						from 3rd-party sources, or just update an already installed software automatically via the normal update procedure.
						The <literal>bundle</literal> tag can coexist with the <literal>pkgname</literal> tag, in case a component is available from
						multiple sources.
					</para>
					<para>
						The <literal>type</literal> property of this tag indicates which 3rd-party software installation solution the bundle belongs to.
						Currently supported solutions are:
						<itemizedlist>
							<listitem><para>The <ulink url="http://people.freedesktop.org/~mak/limba/">Limba Project</ulink>, using the value <code>limba</code>.</para></listitem>
							<listitem><para> <ulink url="https://github.com/alexlarsson/xdg-app">xdg-app</ulink> bundles, using the value <code>xdg-app</code>.</para></listitem>
						</itemizedlist>
					</para>
					<para>
						Example:
					</para>
					<programlisting language="XML"><![CDATA[<bundle type="limba">foobar-1.0.2</bundle>]]></programlisting>
				</listitem>
			</varlistentry>

		</variablelist>
	</section>

<!--
	<section id="spec-asxml-tags-font">
		<title>Valid tags for the font component</title>
		<para>
			Additionally to the other components, the <literal>type=font</literal> component knows a few more allowed tags.
		</para>

		<variablelist>
			<varlistentry>
			<term>&lt;font_classifier/&gt;</term>
			<listitem>
				<para>
					Define a description of the font face to caption it when compared against other fonts in the same family.
				</para>
				<para>
					You can find more information about this tag in <xref linkend="spec-fontdata-filespec"/>.
				</para>
			</listitem>
			</varlistentry>

			<varlistentry>
			<term>&lt;font_parent/&gt;</term>
			<listitem>
				<para>
					The name of the font package this particular font is part of. This is a required tag.
				</para>
			</listitem>
			</varlistentry>
		</variablelist>
	</section>
-->

	<section id="spec-asxml-example">
		<title>Example file</title>
		<para>
			This is an example AppStream metadata file:
		</para>
		<programlisting language="XML">
<![CDATA[<?xml version="1.0"?>
<components version="0.6">
  <component type="application">
    <id>firefox.desktop</id>
    <pkgname>firefox-bin</pkgname>
    <name>Firefox</name>
    <name lang="en_GB">Firefoux</name>
    <summary>Web browser</summary>
    <summary lang="fr_FR">Navigateur web</summary>
    <project_license>MPL-2</project_license>
    <keywords>
      <keyword>internet</keyword>
      <keyword>web</keyword>
      <keyword>browser</keyword>
      <keyword lang="fr_FR">navigateur</keyword>
    </keywords>
    <icon type="stock">web-browser</icon>
    <icon type="cached">firefox.png</icon>
    <categories>
      <category>network</category>
      <category>web</category>
    </categories>
    <mimetypes>
      <mimetype>text/html</mimetype>
      <mimetype>text/xml</mimetype>
      <mimetype>application/xhtml+xml</mimetype>
      <mimetype>application/vnd.mozilla.xul+xml</mimetype>
      <mimetype>text/mml</mimetype>
      <mimetype>application/x-xpinstall</mimetype>
      <mimetype>x-scheme-handler/http</mimetype>
      <mimetype>x-scheme-handler/https</mimetype>
    </mimetypes>
    <url type="homepage">http://www.mozilla.com</url>
    <screenshots>
      <screenshot type="default">
        <image type="source" width="800" height="600">http://www.awesomedistro.example.org/en_US/firefox.desktop/main.png</image>
        <image type="thumbnail" width="200" height="150">http://www.awesomedistro.example.org/en_US/firefox.desktop/main-small.png</image>
      </screenshot>
    </screenshots>
    <provides>
      <binary>firefox</binary>
    </provides>
  </component>
  <component>
    <id>pulseaudio</id>
    <name>PulseAudio</name>
    <summary>The PulseAudio sound server</summary>
    <url type="homepage">http://www.freedesktop.org/wiki/Software/PulseAudio/</url>
    <project_license>GPLv2</project_license>
    <provides>
      <library>libpulse-simple.so.0</library>
      <library>libpulse.so.0</library>
      <binary>start-pulseaudio-kde</binary>
      <binary>start-pulseaudio-x11</binary>
    </provides>
    <release version="2.0"/>
  </component>
  <component type="font">
    <id>LinLibertine_M.otf</id>
    <name>Libertine</name>
    <summary>Linux Libertine Open fonts</summary>
    <font_classifier>Mono</font_classifier>
    <font_parent>Libertine</font_parent>
  </component>
  <!-- more components here! -->
</components>]]></programlisting>

	</section>
</section>
