diff --git a/ra/ra-metadata-example.xml b/ra/ra-metadata-example.xml
index e41a3e8..3f4a97f 100644
--- a/ra/ra-metadata-example.xml
+++ b/ra/ra-metadata-example.xml
@@ -1,88 +1,104 @@
-To: ocf@lists.community.tummy.com
-Subject: [OCF]RFC: Resource Agent metadata format
-Date: Thu, 14 Mar 2002 23:18:02 +0100
+<?xml version="1.0"?>
+<!DOCTYPE resource-agent SYSTEM "http://www.opencf.org/standards/ra-ap-1.dtd">
 
+<!-- Root element: give the name of the Resource agent -->
+<resource-agent name="Filesystem">
 
-<?xml version="1.0"?>
-<!DOCTYPE resource-agent-description SYSTEM "ocf-ra.dtd">
-<resource-agent-description name="Filesystem" ocf-version="1">
-<parameters>
+<!-- Version number of the standard this complies with -->
+<version>1.1</version>
 
-<parameter name="Mountpoint" type="string">
-<longdesc>
-In this case, this is the first parameter in the list; this also implies it is
-the description of the <b>resource name</b>, the unique identifier used to
-name the resource.
+<!-- A full pathname to the RA executable -->
+<executable>/usr/ocf/sbin/filesystem"</executable>
 
-This is the long, helpful description of what the <b>Mountpoint</b> parameter is all
-about. A user interface might display it to the user if he asks for elaborate
-help with an option, and it would obviously also provide examples etc.
+<!-- In addition to providing our own type, we might provide an abstract
+     class; this doesn't make much sense here; it is an optional element
+     and just included for completeness. -->
+<provides>Mountpoint</provides>
+ 
+<!-- List all the instance parameters the RA supports or requires. -->
+<parameters>
 
+<!-- Note that there should be only one parameter with the resource-key flag
+     set; this signifies this is the one describing the resource name.
+ -->
+ 
+<parameter name="Mountpoint" resource-key="1">
+<!-- This is the long, helpful description of what the parameter is all
+     about. A user interface might display it to the user if he asks for 
+     elaborate help with an option, and it would obviously also provide 
+     examples etc.
+     
+     You can have multiple ones with different "lang" attributes, but this is
+     not required.
+-->
+<longdesc lang="en">
+The resource name is the directory where the filesystem will be actually mounted. 
+Please make sure it exists.
 </longdesc>
-<shortdesc>Displayed on mouse over, for example</shortdesc>
-<default>The default value for the parameter, empty or not listed if it has no
-default</default>
+
+<!-- The shortdesc may be displayed by the resource manager as a tooltip or
+     equivalent -->
+<shortdesc>Mountpoint</shortdesc>
+
+<!-- Further definition of the content; used by a GUI or something for
+     verifying user input. -->
+<content type="string" format="^/[:alnum:]+$" default="/mnt" />
+
 </parameter>
 
-<parameter name="Device" type="string">
+<parameter name="Device">
 <longdesc>
 When mounting a filesystem on a specific mountpoint, you have to specify which
 device should be mounted; this will usually be similiar to /dev/sda1 or
 /dev/volumegroup/logicalvolume when using LVM.
 </longdesc>
 <shortdesc>Device to be mounted</shortdesc>
+<content type="string" format="^/dev/"/>
+<!-- This is a dependency on a "Blockdevice" resource; instead of specifying
+     the Device manually, the adminstrator could set the dependency and the
+     RM would provide the resource name of the dependency as the parameter
+     value. -->
+<dependency type="Blockdevice"/>
 </parameter>
 
-<parameter name="FSType" type="string">
+<parameter name="FSType">
 <longdesc>
 You should chose a journaled filesystem for the shared storage to ensure that
 the filesystem remains consistent and that it can be mounted without an
 expensive fsck run; recommendations include reiserfs, ext3 and XFS.
 </longdesc>
 <shortdesc>Type of the filesystem</shortdesc>
-<default>reiserfs</default>
+<content type="enum" format="reiserfs,ext2,ext3,jfs,xfs" default="reiserfs"/>
 </parameter>
 
-<parameter name="mount_options" type="string">
+<parameter name="mount_options">
 <longdesc>
 The mount options used for mounting a filesystem; normally this is set to
-<b>defaults</b>, but you may want to modify this if you require a read-only
+defaults, but you may want to modify this if you require a read-only
 mount or something similar.
 </longdesc>
 <shortdesc>Mount options for this filesystem</shortdesc>
-<default>defaults</default>
+<content type="string" default="defaults" />
 </parameter>
 
 </parameters>
 
+<!-- List the actions supported by the RA -->
 <actions>
-<start timeout="200" />
-<stop  timeout="100" />
-<!-- For a filesystem, it obviously makes no sense to try a local remount if
-     it failed -->
-<restart timeout="150" tries="0" />
-<status timeout="60" interval="30" start-delay="50" />
-<!-- This one _can_ be asked what it depends on; a resource of the
-     type or providing the capability "Blockdevice" as defined below; while 
-     the class in general depends on a generic capability to be present, a
-     specific instance of a Filesystem can also tell the RM which one exactly,
-     -->
-<dependencies timeout="60" />
-</actions>
+<!-- Valid actions: start, stop, restart, status, reload
+     The timeout is given in seconds.
+  -->
+<action name="start"   timeout="200" />
+<action name="stop"    timeout="100" />
+<!-- This is a mandatory action, but the RA suggests to the RM that
+     it doesn't make sense. -->
+<action name="restart" timeout="150" tries="0" />
+<action name="status"  timeout="60" interval="30" start-delay="50" />
+<!-- If the RA _does_ support the graceful reload of its configuration on
+     request, it should advertise the reload action here; this is an optional
+     element! -->
+<action name="reload"  timeout="60" />
 
-<dependencies>
-<!-- Which resource types / capabilities have to be present in a resource
-group before this one can be started? This also implicitly defines the
-start/stop order of the resources -->
-<requires type="Blockdevice" count="1" />
-
-<!-- In addition to the fact that we implicitly provide our own resource type,
-     we might provide additional capabilities; ie, while both a SCSI
-     reservation and a ICP Vortex cluster reservation provide a
-     "SCSIReserve" or "ICP_volume" respectively, both of them provide a
-     "Blockdevice", which could be listed like this -->
-<provides type="Mountpoint" />
-
-</dependencies>
+</actions>
 
-</resource-agent-description>
+</resource-agent>