- From: Dominique Hazael-Massieux via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 29 Jun 2011 07:50:37 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/contacts
In directory hutz:/tmp/cvs-serv23798
Modified Files:
Overview.html
Log Message:
editorial bug fixes (reported by Josh http://www.w3.org/mid/6A252AE18765C3468EF06946F24F0B571FFBF8F801@XCH102CNC.rim.net )
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/contacts/Overview.html,v
retrieving revision 1.147
retrieving revision 1.148
diff -u -d -r1.147 -r1.148
--- Overview.html 15 Jun 2011 15:04:12 -0000 1.147
+++ Overview.html 29 Jun 2011 07:50:35 -0000 1.148
@@ -116,14 +116,14 @@
Every operating system and a large number of web-based service providers have different ways of
representing address book information. Most users are required to maintain a plurality of contact lists
which leads to multiple copies of address book data. This in turn
- often leads to disjointed and inconsistent information being stored across a user's
+ often leads to disjoint and inconsistent information being stored across a user's
address book providers.
</p>
<p>
When sharing contact data with third parties users are, more often than not, required to hand over access to
their whole address book. Users are implicitly required to trust third parties with all of their data
when, in reality, the user may only wish, or need, to share a subset of their address book information so
- that an application can fulfil its purpose.
+ that an application can fulfill its purpose.
</p>
<p>
This specification defines the concept of a user's unified address book - where address book data may
@@ -136,14 +136,14 @@
</p>
<p>
A set of <a href="#security-and-privacy-considerations">Security and Privacy Considerations</a> are
- presented for the discretion of both implementors of the Contacts API and recipients of contact
+ presented for the discretion of both implementers of the Contacts API and recipients of contact
information (i.e. web pages). This specification provides a set of non-normative
<a href="#user-interaction-guidelines">User Interaction Guidelines</a> demonstrating an example user experience
that is compliant with the Security and Privacy Considerations described herein.
</p>
<p>
This specification also provides informative examples illustrating how to
- <a href="#adding-and-updating-contacts">add and update contact information</a>, utilising existing web platform
+ <a href="#adding-and-updating-contacts">add and update contact information</a>, utilizing existing web platform
APIs.
</p>
<p>
@@ -217,15 +217,14 @@
ensure that no contact information is retrievable without the user's express permission.
</p>
<section>
- <h2>Privacy considerations for implementors of the Contacts API</h2>
+ <h2>Privacy considerations for implementers of the Contacts API</h2>
<p>
A <a class="product-ua" href="#ua">user agent</a> MUST NOT provide contact information to Web sites without the express
permission of the user. A <a>user agent</a> MUST acquire permission through a user interface, unless
they have prearranged trust relationships with users, as described below. The user interface MUST
include the <a>document base URL</a>. Those permissions that are acquired through the user interface
and that are preserved beyond the current browsing session (i.e. beyond the time when the <a>browsing
- context</a> is navigated to another URL) MUST be revocable and a <a>user agent</a> MUST respect revoked
- permissions.
+ context</a> is navigated to another URL) MUST be revocable and a <a>user agent</a> MUST respect permission revocation.
</p>
<p>
Obtaining the user's express permission to access one API method does not imply the user has granted
@@ -240,7 +239,7 @@
interfaces. For example, while a Web browser will present a user interface when a Web site performs an
address book request, a Widget [[WIDGETS]] runtime MAY have a prearranged, delegated security
relationship with the user and, as such, a suitable alternative security and privacy mechanism with
- which to authorise the retrieval of contact information.
+ which to authorize the retrieval of contact information.
</p>
</section>
@@ -257,7 +256,7 @@
<p>
Recipients should dispose of contact information once that task is completed, unless expressly
permitted to retain it by the user. Recipients should also take measures to protect this information
- against unauthorised access. If contact information is stored, users should be allowed to update and
+ against unauthorized access. If contact information is stored, users should be allowed to update and
delete this information.
</p>
<p>
@@ -281,7 +280,7 @@
<section class='informative'>
<h2>Additional implementation considerations</h2>
<p>
- Further to the requirements listed in the previous section, implementors of the Contacts API are
+ Further to the requirements listed in the previous section, implementers of the Contacts API are
also advised to consider the following aspects that can negatively affect the privacy of their users:
in certain cases, users can inadvertently grant permission to the <a>user agent</a> to disclose their contacts
to Web sites. In other cases, the content hosted at a certain URL changes in such a way that the
@@ -516,7 +515,7 @@
<dd>
<p>
This attribute contains one or more user-defined categories/tags/labels associated with this
- <a>Contact</a>. e.g. "family", "favourite", "cryptozoologists".
+ <a>Contact</a>. e.g. "family", "favorite", "cryptozoologists".
</p>
</dd>
<dt>attribute ContactField[]? urls</dt>
@@ -548,7 +547,7 @@
This attribute contains the full name, including all the individual components such as
<code>givenName</code>, <code>middleName</code>, <code>familyName</code>, <code>prefix</code>,
<code>suffix</code> as appropriate for the user's culture, and formatted for display (e.g. <code>Mr. Joe Smith
- Jr</code>).
+ Jr.</code>).
</p>
</dd>
<dt>attribute DOMString? familyName</dt>
@@ -579,7 +578,7 @@
<dt>attribute DOMString? honorificSuffix</dt>
<dd>
<p>
- This attribute contains the honorific suffix of this <a>Contact</a>. E.g. Jr, III, Sr.
+ This attribute contains the honorific suffix of this <a>Contact</a>. E.g. Jr., III, Sr.
</p>
</dd>
</dl>
@@ -1047,7 +1046,7 @@
<p>
The properties and parameters defined on the <a href="#contact-interface"><code>Contact</code></a>
- interface MAY be extended by implementors of this specification.
+ interface MAY be extended by implementers of this specification.
</p>
<p>
@@ -1399,7 +1398,7 @@
<p>
The ability to add and update contact information is not a function of the API provided in this
specification. Instead, the intention is to reuse existing web platform APIs and paradigms in order to
- acheive add and update functionality.
+ achieve add and update functionality.
</p>
<p>
@@ -1461,7 +1460,7 @@
<li>Let <var>MatchedContact</var> be the result of obtaining a Contact object from the user's
unified address book that matches exactly the value of the <code>UID</code> provided.</li>
- <li>If a <var>MatchedContact</var> has been found (i.e <var>MatchedContact</var> is
+ <li>If a <var>MatchedContact</var> has been found (i.e. <var>MatchedContact</var> is
not-<code>null</code>) then update the contents of <var>MatchedContact</var> with the contents of
<var>Contact</var> and exit this rule.</li>
</ol>
Received on Wednesday, 29 June 2011 07:50:38 UTC