- From: Richard Tibbett via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 18 Dec 2009 12:56:19 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/contacts
In directory hutz:/tmp/cvs-serv1452
Modified Files:
Overview.html
Log Message:
Added snapshot of issues and notes to specification based on mailing list feedback.
http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0214.html
http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0219.html
Will require further discussion on list.
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/contacts/Overview.html,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -d -r1.20 -r1.21
--- Overview.html 16 Dec 2009 16:15:34 -0000 1.20
+++ Overview.html 18 Dec 2009 12:56:17 -0000 1.21
@@ -345,6 +345,9 @@
readonly attribute DOMString id
</dt>
<dd>
+ <p class='note'>
+ Perhaps we don't want to recommend the use of UUID URN here. Saying that id must be globally unique could suffice, and there may be good reasons why someone would want to use something else (e.g. a SHA mailbox as in FOAF).
+ </p>
<p>A globally unique identifier for the given <code>Contact</code> object. Each <code>Contact</code> referenced from <code>Contacts</code> MUST include a non-empty <code>id</code> value.</p>
<p>An implementation MUST maintain this globally unique resource identifier when a Contact is added to, or present within, an Address Book.</p>
<p>An implementation MAY use an IANA registered identifier format. The value can also be a non-standard format.</p>
@@ -513,6 +516,12 @@
attribute ContactField[] addresses
</dt>
<dd>
+ <p class='note'>
+ May need to align this attribute with ongoing work in the <a href='http://dev.w3.org/geo/api/spec-source-v2.html#address_interface'>Geolocation v2 specification</a>.
+ </p>
+ <p class='note'>
+ Define a ContactAddress interface and break addresses in to individual components?
+ </p>
<p>One or more addresses associated with the contact.</p>
<p>The first object in this sequence is inferred to be the user's preferred/default address.</p>
@@ -543,10 +552,9 @@
<dd>
<p>An identifier that MAY be provided that represents the address book owner of the current contact object.</p>
<p>This attribute enables multiple address book sources to be tagged and filtered on Contact objects.</p>
- <p>It is recommended that an implementation assign the serviceId attribute as a Formal Public Identifier as defined in [[ISO9070]].</p>
+ <p>It is recommended that an implementation assign the serviceId attribute as a URI.</p>
- <pre class="example sh_javascript_dom">{serviceId: '-//Foobar Inc//ENTITIES FooBar AddressBook 1.0//EN'}</pre>
- <pre class="example sh_javascript_dom">{serviceId: '-//BarFoo//ENTITIES MyContacts 1.4//EN'}</pre>
+ <pre class="example sh_javascript_dom">{serviceId: 'http://foobar.com/calendar'}</pre>
</dd>
<dt>
attribute DOMString[] categories
@@ -583,6 +591,20 @@
<section>
<h2><a>ContactOptions</a> interface</h2>
+ <p class='note'>
+ Rename this to "ContactSearchFilter" or similar?
+ </p>
+ <p class='note'>
+ The options provided in this interface seem to be fairly generic in nature and wondering if we could provide a generic search framework
+ that can be used across all APIs (e.g. contacts, calendar, messaging, etc.).
+
+ <br /><br />
+ Probably yes, but:
+ <br />1) it needs to be better specified before we do that, and
+ <br />2) we can wait a little before we do some merging. One option to investigate is to look at the multiple existing DB specs that WebApps is progressing, and to use something from there if there happens to be something usable.
+ </p>
+
+
<p>
The <a href='#contactoptions-interface'><code>ContactOptions</code></a>
interface describes the options that can be applied to contact searching.
@@ -614,6 +636,9 @@
attribute DOMString? sort
</dt>
<dd>
+ <p class='note'>
+ Would it be better to have sort: ['field1', 'field2'] and descending: true|false where the latter is only meaningful if sort was specified?
+ </p>
<p>
The way to sort the first enumerable <a href='#contactproperties-interface'><code>ContactProperties</code></a> attribute provided in the related method.
</p>
@@ -630,6 +655,9 @@
attribute DOMString? group
</dt>
<dd>
+ <p class='note'>
+ Perhaps it is not possible to determine what the first enumerable ContactProperties attribute is since it's not ordered??
+ </p>
<p>
The way to group the first enumerable <a href='#contactproperties-interface'><code>ContactProperties</code></a> attribute provided in the related method.
</p>
@@ -795,6 +823,9 @@
<!-- end api description section -->
<section>
<h2><a>Contact Search Processing Rules</a></h2>
+ <p class='issue'>
+ The algorithm doesn't yet take ContactOptions in to account. This should be added in next update.
+ </p>
<p>
The <a href="#contacts-interface"><code>Contacts</code></a> interface <a href='#widl-Contacts-find'>find()</a> method
provides a method to search for contacts according to the input of a
@@ -816,6 +847,9 @@
The above example logically implies: <em>"find contact objects that contain a name of 'Robert' AND a nickname of 'Bob'"</em>.
</p>
+ <p class='note'>
+ We need to be a lot clearer about partial matching included below. It might just be simpler to use pass RegExp objects around. Then again it might not :)
+ </p>
<p>
All contact searching SHOULD apply a loose-matching policy. If a <a href='#contactproperties-interface'><code>ContactProperties</code></a> attribute being searched in <a href='#contacts-interface'><code>Contacts</code></a>
<em>partially matches</em> the input filter value, a <a href='#contact-interface'><code>Contact</code></a> object representing the contact
@@ -824,7 +858,7 @@
<p>The <dfn id='rules-for-processing-filter-combinations'>rules for processing filter combinations</dfn> is defined below and is always provided with one <var title="">input</var> parameter. Its behaviour depends on the type of <var title="">input</var>:</p>
- <dl class=switch>
+ <dl class='switch'>
<dt></dt>
<dd>Let <var title="">contactsset</var> be initially the set of all known contacts</dd>
Received on Friday, 18 December 2009 12:56:23 UTC