2 files changed, 25 insertions, 42 deletions
diff --git a/doc/src/contacts.qdoc b/doc/src/contacts.qdoc
index 84dbc727a9..f6d74989b9 100644
--- a/doc/src/contacts.qdoc
+++ b/doc/src/contacts.qdoc
@@ -56,15 +56,16 @@ remote backends. This is part of the Qt Mobility Project.
 
 \section1 Introduction
 
-Access to the backends is provided by implementations of Qt Contacts
-manager API.  This is achieved by defining generic personal information
-data abstractions which can sufficiently describe contact data stored on
-any platform. Due to the cross-platform nature of the API, and the ability
-for developers to write platform-independent implementations of a
-QContactManager which may unify one or more platform specific contact
-backends, it is intended that the semantics and quirks of the underlying
-datastores on any platform may be entirely opaque from the perspective of
-Qt-based, cross-platform client applications.
+The Contacts API provides clients with the ability to access contact data
+in a platform-independent and datastore-agnostic manner.  This is achieved
+by defining generic personal information data abstractions which can
+sufficiently describe contact data stored on any platform.  Due to the
+cross-platform nature of the API, and the ability for developers to write
+platform-independent implementations of a QContactManager which may unify
+one or more platform-specific contact backends, it is intended that the
+semantics and quirks of the underlying datastores on any platform may be
+entirely opaque from the perspective of Qt-based, cross-platform client
+applications.
 
 \section1 Overview 
 
@@ -105,13 +106,14 @@ schema, and arbitrary relationship types are also allowed.  In particular,
 membership of a contact in a group can be modeled as that group contact
 participating in a \c HasMember relationship with the contact.
 
-A manager provides access to zero or more platform-specific datastores.
-Each datastore may support different capabilities (for example, the ability
-to store certain datatypes, the ability to natively filter on different
-details or details of different definitions, the provision of locking
-mechanisms, the provision of changelog information, etc) which are reported
-by the manager on request.  The manager therefore provides access to detail
-definitions, contacts, and relationships stored in different datastores,
+Access to the contacts is provided by implementations of the Qt Contacts
+manager API. A manager provides access to zero or more platform-specific
+datastores.  Each datastore may support different capabilities (for example,
+the ability to store certain datatypes, the ability to natively filter on
+different details or details of different definitions, the provision of
+locking mechanisms, the provision of changelog information, etc) which are
+reported by the manager on request.  The manager therefore provides access to
+detail definitions, contacts, and relationships stored in different datastores,
 in a platform and datastore independent manner. The engine of a manager may
 be implemented as a plugin to allow dynamic loading of different engines at
 run-time.
@@ -264,7 +266,7 @@ they may offer their own which provide similar functionality.
 \annotatedlist contacts-details
 
 Each of these subclasses provide access to information stored in fields which
-are listed in the \l{Qt Contacts Schema}{schema}.
+may have certain constraints, as listed in the \l{Qt Contacts Schema}{schema}.
 
 \section2 Asynchronous Requests
 
diff --git a/doc/src/contactsschema.qdoc b/doc/src/contactsschema.qdoc
index 22b595e0fa..c0f8907613 100644
--- a/doc/src/contactsschema.qdoc
+++ b/doc/src/contactsschema.qdoc
@@ -74,28 +74,8 @@ the default schema will work without source modification against their backend.
 \section1 Default Schema
 
 The leaf details that form the default schema are as follows:
-\list
-    \o \l{QContactAddress}
-    \o \l{QContactAnniversary}
-    \o \l{QContactAvatar}
-    \o \l{QContactBirthday}
-    \o \l{QContactDisplayLabel}
-    \o \l{QContactEmailAddress}
-    \o \l{QContactFamily}
-    \o \l{QContactGender}
-    \o \l{QContactGeolocation}
-    \o \l{QContactGuid}
-    \o \l{QContactName}
-    \o \l{QContactNickname}
-    \o \l{QContactNote}
-    \o \l{QContactOnlineAccount}
-    \o \l{QContactOrganization}
-    \o \l{QContactPhoneNumber}
-    \o \l{QContactSyncTarget}
-    \o \l{QContactTimestamp}
-    \o \l{QContactType}
-    \o \l{QContactUrl}
-\endlist
+\annotatedlist contacts-details
+
 
 In the default schema, each of these definitions have various access and uniqueness constraints.
 Additionally, fields of the definitions may have an access constraint of read-only defined for them.
@@ -148,10 +128,11 @@ the default display label for the contact.
 Furthermore, some fields of some definitions are also constrained to be read-only.  This is information which is generated or automatically
 provided by the backend, which is related to user-provided information that is also stored in the detail.
 
-The eponymous example of this is the \l{QContactOnlineAccount} leaf detail, which has an unconstrained field which stores the URI of the
-account, and several read-only fields in which are stored presence information, status messages, and service availability.
+The eponymous example of this is the \l{QContactOnlineAccount} leaf detail, which has unconstrained fields which store the URI and service
+provider of the account, and several read-only fields in which are stored presence information, status messages, and service availability.
 
 Currently, the \l{QContactOnlineAccount} is the only leaf detail with field-level access constraints.  Every field in details of this
-type are \c QContactDetailDefinition::ReadOnly except for \c QContactOnlineAccount::FieldAccountUri, which has no constraint.
+type are \c QContactDetailDefinition::ReadOnly except for \c QContactOnlineAccount::FieldAccountUri and
+\c QContactOnlineAccount::FieldServiceProvider, which have no constraint.
 
 */