W3C

List of comments on “Contacts API” (dated 16 June 2011)

Quick access to

There are 21 comments (sorted by their types, and the section they are about).

1-20 21-21

question comments

Comment LC-2528
Commenter: Internationalization Core Working Group Issue Tracker <sysbot+tracker@w3.org> (archived message)
Context: Document as a whole
I18N-ISSUE-68: explicit support for CHARSET attribute [Contacts API]

http://www.w3.org/International/track/issues/68

Raised by: Koji Ishii
On product: Contacts API

(general)
http://dev.w3.org/2009/dap/contacts/

WG Approved: Yes.

The document doesn't define a specific version supported by the API. Version 2.1 included a CHARSET type parameter that version 3.0 eliminates. Please clarify how character encodings should be handled or whether 'charset' is supported.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2520
Commenter: Charles McCathieNevile <chaals@opera.com> (archived message)
Context: in
Hi,

This comment is from me as an individual

it's not clear from the specification how to use name.formatted,
displayName and nickName properly. As I understand from reading the
reference given, an example from my life is that my friend's name is
rendered "John John" in my address book, which is neither the
nickname I use to search for him nor the way it should be rendered as a
formatted name.

But since I am unclear, having read the spc and reference carefully, I
would appreciate examples directly placed in the contacts API spec.

cheers

Chaals
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2524
Commenter: Internationalization Core Working Group Issue Tracker <sysbot+tracker@w3.org> (archived message)
Context: 4.2.1 Methods find Find contacts in the address book acc...
I18N-ISSUE-65: find() method case sensitivity [Contacts API]

http://www.w3.org/International/track/issues/65

Raised by: Koji Ishii
On product: Contacts API

Section 4.2.1
http://dev.w3.org/2009/dap/contacts/#methods

WG Approved: Yes

It isn't clear if the find() method is case sensitive or not. Section 5, which talks about "Contact Search Processing" uses the term "match" without closely defining what constitutes a match. We think case sensitivity of the find() method and search processing in general should be defined.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2529
Commenter: Internationalization Core Working Group Issue Tracker <sysbot+tracker@w3.org> (archived message)
Context: 4.4 ContactName interface The ContactName interface describ...
I18N-ISSUE-69: Support for reading/phonetic/pronunciation fields [Contacts API]

http://www.w3.org/International/track/issues/69

Raised by: Koji Ishii
On product: Contacts API

Section 4.4: ContactName
http://dev.w3.org/2009/dap/contacts/#idl-def-ContactName

WG Approved: Yes

The fields defined in the ContactName interface do not include fields for "pronunciation" (also called variously "furigana", "reading", or "phonetic"). These fields are necessary to support East Asian cultures and names, since the pronunciation information is important for both sorting/organizing names (Chinese and Japanese ideographs do not contain this information directly).

Many vendors support this via proprietary X- extension fields. Lack of interchange for these fields represents a significant barrier for global name catalogs.

Please add optional pronunciation fields for at least the family and given name fields.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2530
Commenter: Internationalization Core Working Group Issue Tracker <sysbot+tracker@w3.org> (archived message)
Context: 4.4 ContactName interface The ContactName interface describ...
I18N-ISSUE-70: Support multiple family names [Contacts API]

http://www.w3.org/International/track/issues/70

Raised by: Koji Ishii
On product: Contacts API

Section 4.4 ContactName
http://dev.w3.org/2009/dap/contacts/#idl-def-ContactName

WG Approved: Yes

In a number of cultures, multiple family names can appear in an individual's name. See, for example [1]. Because there is only one familyName field, it is unclear how to support multiple family names. For example, in some cultures, the family name appears in the middle of the name string: the well-known writer "Gabriel García Márquez" has two familial names--"García" and "Márquez". The former name is considered his surname.

Please provide guidance on handling multiple family names.




[1] http://www.w3.org/International/questions/qa-personal-names
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2522
Commenter: Wonsuk Lee <wonsuk73@gmail.com> (archived message)
Context: Document as a whole (URL based approach vs JSON approach)
Dear all,

A few days ago, my colleague starts to contribute the implementation
of Calendar API to Webkit community. So, it results in triggering to
start the discussion of Calendar API in the community. but concerning
to the implementation of most of device API, one of reviewer give a
comment as web-friendly URL-based approach is better way than the
implementation within the webkit itself. What do you think ? I would
like to propose to discuss this issue during F2F meeting.

Please refer the original email [1] from the webkit reviewer.

See you soon in Orange Lab~ ;)

[1] https://lists.webkit.org/pipermail/webkit-dev/2011-July/017621.html

best regards,
Wonsuk.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2558
Commenter: Andreas Gal <gal@mozilla.com> (archived message)
Context: Document as a whole
Several classes implement a formatted field that is defined as:

This attribute contains the full physical address including street, locality, region, postalCode, and country as appropriate, and formatted for display.

Is this supposed to be active (e.g. if I change region on an address, it automatically updates), or is this a snapshot?

If we allow diverging formatting, writing these objects back (assuming we do add an edit feature) becomes pretty confusing. If we don't plan on adding edit, why are these fields not readonly?

Andreas

[NoInterfaceObject]
interface
ContactAddress
{
attribute boolean pref;
attribute DOMString? type;
attribute DOMString? formatted;
attribute DOMString? streetAddress;
attribute DOMString? locality;
attribute DOMString? region;
attribute DOMString? postalCode;
attribute DOMString? country;
};
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2523
Commenter: Josh Soref <jsoref@rim.com> (archived message)
Context: Document as a whole
The contacts[1]/calendar[2] API's currently have text like this:
> The user interface must include the URI of the document origin, as
> defined in [HTML5].

And I wrote in [3][4] that this was a bad idea...

Google is in the process of removing the URL bar from Chrome [5] and Mozilla has been working through removing it from Firefox [6][7] for some time too. The reality, as I noted in my comments is that users don't understand URIs, so they do not add security. As showing URIs to user neither adds nor enables security, specifications shouldn't demand that they be shown to users.

[1] http://www.w3.org/TR/2011/WD-contacts-api-20110616/

[2] http://www.w3.org/TR/2011/WD-calendar-api-20110419/

[3] http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0081.html

[4] http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0095.html

[5] http://www.conceivablytech.com/7485/products/google-is-serious-you-can-kill-chromes-url-bar

[6] https://wiki.mozilla.org/Firefox/Features/Toolbarless

[7] http://mozillalabs.com/conceptseries/2011/05/24/community-concepts-ubiquitous-firefox-part-1-how-do-you-design-a-debris-less-browser/



---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2514
Commenter: Dominique Hazael-Massieux <dom@w3.org> (archived message)
Context: Document as a whole
Not assigned
Resolution status:

Le mercredi 08 juin 2011 à 14:26 +0200, Robin Berjon a écrit :
> >> For photos I think it's an easy win. The current draft has Base64 or
> >> URI. We could just have URI, indicating that if it's Base64 it can be
> >> a data: URI (and it could also be a blob: URI).
> >
> > Photos are clearly my #1 request; having a field that can have both URLs
> > and binary-encoded-data-but-not-a-data-URL seems like non-sense.
>
> For photos I certainly agree that it's a bug in the spec to have the two variants that we currently have.

As discussed during the call, let's start with fixing this for photos,
and leave the other fields alone for the time being. Based on
implementers/developers feedback, we can always revisit that later.

That would be the resolution for ISSUE-111.

Dom
ISSUE-111
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2515
Commenter: Dominique Hazael-Massieux <dom@w3.org> (archived message)
Context: Document as a whole
Not assigned
Resolution status:

Hi,

The Contacts API currently defines it find() method as special caller
method; I'm not sure why it is so, but that's not compatible with Web
IDL: the find() method has optional arguments, and Web IDL forbids
special operations with optional arguments.

The Calendar API has the same issue.

Dom
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2519
Commenter: Lars Erik Bolstad <lbolstad@opera.com> (archived message)
Context: Document as a whole
On 26.05.2011 12:03, Robin Berjon wrote:
> Hi Doug,
>
> On May 25, 2011, at 18:48 , Doug Turner wrote:
>> I'd like to avoid option A, but also would like to see the
>> |address| object that geolocation uses be more or less compatible
>> with the one contacts uses. Given the few exceptions you listed, I
>> don't see any reason not to just use your judgement and move
>> ahead.
>
> If you think that alignment is preferable, I certainly see no reason
> to object to it. To state my preference in less jocular terms, I
> don't think that alignment is necessary, but of course if it's easily
> reached then it's certainly nice to have.
>
>> Btw, we considered using the IETF Civic Address. It has a crazy
>> huge address structure and can represent just about any location on
>> earth. We looked closely at this and decided that exposing this
>> structure as-is to the web would basically just cause developer
>> pain. Instead, we decided to just use a simpler 'mailing address'
>> structure.
>
> Yeah, I think that IETF Civic Addresses are intended for more complex
> systems such as postal services backends. I doubt that we need
> anything like that.
>
> What we did was look at vCard, PoCo, and OMA CAB, spoke to the people
> behind those efforts, and found a set of properties that seemed to
> make everyone happy enough while remaining reasonable in scope.
>
> If we're looking at alignment, which parts do you think are most
> important? The easy one is |city| -> |locality|. The most useful
> ones are probably having DAP's |country| be an ISO code and adding
> |formatted| to Geo but this may run into implementability issues. DAP
> has to rely on underlying address book implementations, some of which
> don't normalise countries, and Geo services may not be able to
> provide formatting given the vast international variations (I'm
> guessing, at least). For the other fields, a constraining factor for
> DAP would also be losing compatibility with PoCo/vCard/CAB since
> those are the underlying models that we need to interface with.
>


It would be good if we could align the Address interfaces as much as
possible while still taking our different use cases into account.

It should be trivial to rename attributes to be the same at least.

Lars Erik
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2557
Commenter: Andreas Gal <gal@mozilla.com> (archived message)
Context: 4.2 Contacts interface The Contacts interface exposes a dat...
4.2 Contacts interface

[NoInterfaceObject]
interface Contacts {
caller void find (DOMString[] fields, ContactFindCB successCB, optional ContactErrorCB errorCB, optional ContactFindOptions options);
};

To quote from WebIDL, http://dev.w3.org/2006/webapi/WebIDL/Overview.html#idl-callers

Specifications SHOULD NOT use callers unless required to specify the behavior of legacy APIs. (emphasis theirs, not mine)

Callable objects step outside the semantics of ECMAScript and can't be self-hosted.

I would much prefer if we drop the caller annotation here. Any objections?

Andreas
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2525
Commenter: Internationalization Core Working Group Issue Tracker <sysbot+tracker@w3.org> (archived message)
Context: 4.5.1 Attributes pref of type boolean This attribute indi... (also section 5)
I18N-ISSUE-66: find() method sensitivity to Unicode normalization [Contacts API]

http://www.w3.org/International/track/issues/66

Raised by: Koji Ishii
On product: Contacts API

Section 4.2.1 find method
http://dev.w3.org/2009/dap/contacts/#methods

Section 5
http://dev.w3.org/2009/dap/contacts/#contact-search-processing

WG Approved: Yes

As with I18N-ISSUE-65, the find() method and search processing do not clearly define the details of "match". When processing a search, we feel that it should be clear if Unicode Normalization has been applied to the arguments and/or contacts being searched.

In our WG's opinion, Unicode normalization is desirable when searching, since many keyboards or user-agents generate non-normalized search strings (for example, Vietnamese keyboards vary by vendor). As a result, search strings entered by the user might not match content that uses a different normalization form. For example, a user might enter the pre-composed character U+1EA6 (LATIN CAPITAL LETTER A WITH CIRCUMFLEX AND GRAVE)--or they might enter U+0132 U+0300 instead. [They could also technically use U+00C0 U+030C, although this is less likely.] Ensuring that searches are done in a normalized manner will improve interoperability, since a collection of contacts may have been entered on a variety of devices and into a variety of systems.

The I18N WG recommends requiring comparisons be done in a Unicode normalized manner. We note that this is currently an issue raised before the TAG and guidance here is subject to change. If TAG were to decide that normalization is undesirable, a health warning would be warranted.

For more information on normalization see:

Unicode Standard Annex 15 http://www.unicode.org/reports/tr15/
Character Model-Normalization http://www.w3.org/TR/charmod-norm
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2518
Commenter: Charles McCathieNevile <chaals@opera.com> (archived message)
Context: in
Hi,

This is a comment from me as an individual.

The privacy requirements should be non-normative, or optional. It makes
good sense to say what the privacy implications are and how they should be
handled, but there are legitimate use cases for a system that doesn't
provide a "normal" level of privacy, and it should be possible for such a
system to be conforming. Whether the information is informative, or
optional, it allows people to test implementations and see how much they
respect privacy, without placing what are essentially political limits
(some people would argue that there doesn't need to be so much privacy,
others would like more) on technical implementation.

cheers

Chaals
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2517
Commenter: Charles McCathieNevile <chaals@opera.com> (archived message)
Context: in
Not assigned
Resolution status:

Hi,

the examples used in the spec don't specify that they are trying to get
multiple contacts, but the explanation assumes that they will. This seems
to be an error in them, which could be resolved as an editorial correction.

cheers

Chaals
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2547
Commenter: Michael Cooper <cooper@w3.org> (archived message)
Context: Document as a whole (4.3.1, 7, A.1, A.2, B, tables)
Below is feedback from the Protocols and Formats Working Group on the
Contacts API. Apologies that this arrives so far after the review
deadline, it takes a while to organize group review particularly in the
summer.

(1) Re: 'photos' attribute,
http://www.w3.org/TR/2011/WD-contacts-api-20110616/#attributes-1

The spec does not allow to provide an alternate text or a description to
any of the photos. However, since the photos are meant to be used as
profile photos (explicit note provided), in general the name of the
contact person should be sufficient to be used as alternate text.

(a) The following accessibility-related problem could still occur: A
contact item has a photo, but no name and no displayName is provided
(all attributes except 'id' are optional).

* This would be a clear disadvantage to the visually impaired users.

* Proposed change: Add the following note: "If one or multiple photo
fields are provided, either the 'displayName' or the 'name' attribute
should have reasonable content, thus serving as alternate text for the
photos."

(b) It is not clear what information the 'type' attribute should carry
for a photo item. Is this intentionally left unspecified? The spec would
benefit from clarifying what information should go into the 'type'
attribute for photos, even if only by examples.

Regarding 'type' information on photos, we wonder if this information
would be useful for semantic purposes, in order to be able to
differentiate between multiple photos and their appropriate use. For
example, by marking the photos as "work", "leisure", etc., an
application could automatically suggest an appropriate photo for a
particular situation (e.g. job application, social networking site,
etc.). This would also be helpful for people with visual impairment, as
part of an automatically generated alternate text for the photos.


(2) Re: 7. API Invocation via COM Events,
http://www.w3.org/TR/2011/WD-contacts-api-20110616/#api-invocation-via-dom-events


* The event types mentioned include mainly mouse-specific events
(dblclick, mouseup). However, in the spirit of device-independence a
user should also be able to activate the Contact Picker via keyboard.

* Proposed change: Add "keypress" and "keyup" to the list of allowed
even types..


(3) Re: A.1 Accessing Contact Information ­ Example #1,
http://www.w3.org/TR/2011/WD-contacts-api-20110616/#accessing-contact-information---example‹1

<http://www.w3.org/TR/2011/WD-contacts-api-20110616/#accessing-contact-information---example--1>

* In the example shown, it is not clear what the "Select" operation
applies to. Can the user select the information fields only (as shown on
the left), or can they also select and exclude individual contacts?

* Proposed change: Use checkboxes on the right side to select specific
contacts (the same as on the left side for selecting the information
fields).


(4) Re: A.2 Accessing Contact Information ­ Example #2,
http://www.w3.org/TR/2011/WD-contacts-api-20110616/#accessing-contact-information---example‹2

<http://www.w3.org/TR/2011/WD-contacts-api-20110616/#accessing-contact-information---example--2>

* Why is there no mention of the non-blocking contact search
notification, as in example #1?

* Proposed change: Clarify.


(5) Re: Formatting issue with table header cells in the spec

Header cells in tables (like the table in 4.9.2
<http://www.w3.org/TR/2011/WD-contacts-api-20110616/#event-handler-attributes>)
are displayed as inverted (white on blue). When rolling over its text,
the text color remains white and the background color is set to a light
yellow. This is not readable anymore.

The problematic layout rule is contained in
http://www.w3.org/StyleSheets/TR/W3C-WD, line 56ff:
@media screen { /* hide from IE3 */
a[href]:hover { background: #ffa }
}


(6) Typos

* "acheive" in Section B. Adding and Updating Contacts,
http://www.w3.org/TR/2011/WD-contacts-api-20110616/#adding-and-updating-contacts
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2559
Commenter: Andreas Gal <gal@mozilla.com> (archived message)
Context: 4. API Description 4.1 ServiceContacts interface The Servi...
[NoInterfaceObject]
interface
ContactField
{

attribute DOMString type;
attribute DOMString? value;
attribute boolean pref;
};

Several classes have a pref attribute that is defined as follows:

pref of type boolean
This attribute indicates whether this instance of the ContactField is the preferred, or primary, value for the contact property this ContactField is representing in the Contact interface. By default, the value is false.

I don't think the spec explains what happens if multiple entries have that boolean set, or none.

Also, I wonder if the simple order of appearance might be a sufficient way to specify preference (maybe users want a different display order and preference order?).

Andreas
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2560
Commenter: Andreas Gal <gal@mozilla.com> (archived message)
Context: 4. API Description 4.1 ServiceContacts interface The Servi...
Is there a particular reason for the diverging attribute order in some classes? Example:

[NoInterfaceObject]
interface ContactField
{
attribute DOMString type;
attribute DOMString? value;
attribute boolean pref;
};

[NoInterfaceObject]
interface ContactAddress
{
attribute boolean pref;
attribute DOMString? type;
attribute DOMString? formatted;
attribute DOMString? streetAddress;
attribute DOMString? locality;
attribute DOMString? region;
attribute DOMString? postalCode;
attribute DOMString? country;
};

pref is last and then first.

Since this can be observed from JS, can we pick one meaningful order and stick to that for all classes?

Andreas
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2521
Commenter: Josh Soref <jsoref@rim.com> (archived message)
Context: 4.3.1 Attributes addresses of type array of ContactAddress...
http://dev.w3.org/2009/dap/contacts/#attributes-1


> addresses of type array of ContactAddress, nullable
> This attribute represents one or more physical addresses
> associated with this Contact.

The attribute exists regardless of whether it is null, right? Should it say zero or more? -- This comment applies to all nullable array attributes.

Also, I don't think "represents" is correct, it probably "exposes". -- This comment applies to all attributes claiming to represent things...

Note that later text uses "captures" for the same confusing meaning:

> This attribute captures one or more phone numbers associated with this Contact.

The text should settle on a single phrasing.

> displayName of type DOMString, nullable
> This attribute contains the name of this Contact in a
> form that is suitable for display to the user.

This is a bit nitpicky, if someone sends me a contact card with a displayName of "Дмитрий Медведев", the card I receive isn't invalid, however, for me, that displayName is not suitable. I don't have a great replacement for "suitable for display to the user". I think s/to the user// is probably necessary, possibly s/suitable/preferable/. To use a simpler example, my own card could have a display name of "Josh", but my first name is "Joshua", and both are quite suitable for display to me, as a user, one however is *preferable*.

> An implementation must maintain this globally unique identifier
> when a Contact is added to an address book.

What does this mean? If I have a card "Josh" and I generate a guid for it, and then someone asks me for it, and I give it to them, and then they give me a new card with the same guid and with a name of "Joshua", what is my user agent supposed to do when asked to add it? If the user chooses to create a new card instead of merging the card with the original, then a "must maintain *this* guid" is problematic.

> This attribute should not be used to send down arbitrary
> photos taken by this user, but specifically profile photos
> of the contact suitable for display when describing the contact.

I haven't checked today, but on Facebook, Google Chat, AIM, and most other sites, people often have contact photos which are not specifically "profile[1] photos". On some sites, the content of such a photo could even be "unsuitable for display".

Ignoring that, s/down//; s/describing/showing/

> urls of type array of ContactField, nullable
> This attribute represents one or more URLs associated with
> this Contact e.g. personal web page, blog.
> The web resources must be specified using the value attribute
> of the ContactField object, and its type field may be set to "blog"
> or "profile".

I half expect most of these "type" fields to be null or empty most of the time -- except null isn't allowed for the type field which means it'll have to be empty instead. I also worry about how anyone will deal with them when they cross language boundaries, I mean, if I sent you a Contact.urls: [
{type: "博客", value: "http://博客.example.com/博客/me", pref: false},
{type: "блог", value: "http://блог.example.com/блог/me", pref: false},
], what would you do with the type fields?

http://dev.w3.org/2009/dap/contacts/#contactname-interface


> interface ContactName {
> attribute DOMString? formatted;
> attribute DOMString? familyName;

http://dev.w3.org/2009/dap/contacts/#attributes-2


> familyName of type DOMString, nullable
> formatted of type DOMString, nullable

Is there any reason that the order of the Attribute definitions doesn't match the order of the interface? If the reason is because formatted is special, then perhaps an extra blank line between it and the rest of the fields would be beneficial.

> formatted of type DOMString, nullable
> This attribute contains the full name, including all the individual
> components such as givenName, middleName, familyName, prefix, suffix as
> appropriate for the user's culture, and formatted for display (e.g. Mr.
> Joe Smith Jr.).

The "as appropriate for the user's culture" requirement might be an unreasonable burden for implementers. If I get a contact card from some other data source, I have no idea if that card was formatted for my user's culture or someone else's. It's formatted certainly, but not necessarily for my user (see earlier example of the Russian President). In many cases the UA does not know the user's culture, and there are certainly many cards whose name content would not fit the culture of the user. I also suspect that there are some cultures which wouldn't include all name elements in a card as part of a full name.

> middleName of type DOMString, nullable
> This attribute contains the middle name of this Contact.

Having recently had my middle name stored as the first name of two in my last name field, it's worth noting that many of these name fields can arbitrarily have multiple "names" inside them, especially the middleName and familyName fields. -- In my case it was an error (which has since been corrected). But it's definitely possible to have "El ingenioso hidalgo don Quixote de la Mancha"
possibly: {
title: "El ingenisoso hidalgo", givenName: "don Quixote", familyName: "la Manca", formatted: "El ingenioso hidalgo don Quixote de la Mancha"
}

or "Francisco José de Goya y Lucientes"
possibly: {
givenName: "Francisco", middleName: "José", familyName: "Goya y Lucientes", formatted: "Francisco José de Goya y Lucientes"}

A number of those smaller words will be shoehorned into random other fields. It's possible that some of those smaller words will not be present in any other fields...

Also suggested was "Maria Luisa Josefina Antonieta Vicenta". (Titles for such people are really amusing.)


http://dev.w3.org/2009/dap/contacts/#advanced-search-qualifiers


> We call composed attributes Contact attributes of types object,

"we call" sounds like a definition of <composed attributes>, which would be ok.

> which contain information only available only through child
> attributes of that object, or array.

But ", or array" is confusing and doesn't seem to fit within the structure of the sentence. I think the problem might simply be an extraneous comma before "or array".

> A requesting application must be able to request both the full

s/fully/fully/ ?

> composed Contact attribute and also be able to request individual

s/also.*request//

> parts of a composed Contact attribute

s/$/./

> in the search qualifier provided to a Contacts find() operation.

This part should be moved to the beginning of the sentence:

The SQ of a Contacts find() operation must allow a requesting application to ...

> Example
> The following Contact search is initiated:
> navigator.contacts( ['emails.value', 'name', 'friends'],
> function(contacts) {
> for(i in contacts) {
> for(j in contacts[i].emails)
> alert(contacts[i].emails[j]);
> }
> } );

> The above example logically implies:

> 1. Return only the valid Contact attributes requested in the provided
> search qualifier (name, emails.value - friends is not a valid
> Contact attribute so ignore this element).

I can't figure out which of "name", "emails.value" or "friends" is objectionable according to the parenthetical.

http://dev.w3.org/2009/dap/contacts/#search-filters


> A search filter may be specified from a requesting web
> application to provide a hint to the user agents as to

s/agents/agent/

> which contacts the user can select to share with the
> application.

"can select" is odd, perhaps "which contacts the application would like the user to provide".

> The actual usage of this search filter is user-agent dependant,

s/dependant/dependent/
(you rarely ever want dependant.)

[1] http://www.merriam-webster.com/dictionary/profile?show=0&t=1309803535 : a representation of something in outline; especially : a human head or face represented or seen in a side view

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2531
Commenter: Internationalization Core Working Group Issue Tracker <sysbot+tracker@w3.org> (archived message)
Context: 4.4.1 Attributes familyName of type DOMString, nullable T...
I18N-ISSUE-71: clarify culturally-linked references to name position [Contacts API]

http://www.w3.org/International/track/issues/71

Raised by: Addison Phillips
On product: Contacts API

Section 4.4.1
http://dev.w3.org/2009/dap/contacts/#idl-def-ContactName

WG Approved: No.

The section on contactName attributes contains references such as:

--
familyName of type DOMString, nullable

This attribute contains the family name (also referred to as the last name) of this Contact.
--

The family name is not always the "last name". In some cultures it appears first, for example. Please clarify these cultural references. I would suggest:

"This attribute contains the family name (which is also referred to, in some cultures, as the surname or last name) of this Contact."

Note: this comment also applies to "givenName" ("first name").

As a general observation, it would be useful to provide more international examples of names. "Mr. Joe Smith Jr." is not fully indicative of the richness of people's names.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

1-20 21-21

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org