RE: Review of Web Intents addendum for local services

I have uploaded a new version the addendum specification, http://w3c-test.org/dap/wi-addendum-local-services/.

Thanks again for your review Cathy!

Regards
 Claes

>-----Original Message-----
>From: Nilsson, Claes1
>Sent: den 7 juli 2012 11:31
>To: 'Cathy.Chan@nokia.com'; public-web-intents@w3.org; public-device-
>apis@w3.org
>Subject: RE: Review of Web Intents addendum for local services
>
>Thanks for your review and comments Cathy. It helps a lot!
>
>All comments make sense and I plan to upload a new version on Monday.
>
>Best regards
>  Claes
>
>P.S. I uploaded the specification to CVS again. There was some error in
>the configuration of the DAP repository that made the folder for my
>specification disappear.
>
>>-----Original Message-----
>>From: Cathy.Chan@nokia.com [mailto:Cathy.Chan@nokia.com]
>>Sent: den 5 juli 2012 22:11
>>To: public-web-intents@w3.org
>>Subject: Review of Web Intents addendum for local services
>>
>>Here are my comments on the addendum that Claes uploaded last week.
>(The
>>link is dead as of today by the way.)
>>
>>4.1.1 The actionList tags should be removed. The UDA requires that the
>>actionList must not be listed in the service description when there are
>>no
>>actions.
>>4.1.1 The text description says X_State is ui4 but it's in boolean in
>>the
>>example.
>>4.1.2 [[To support more than one Web Intents action the action strings
>>must
>>be separated with one or more commas.]]
>>- This can be misinterpreted as multiple commas between two action
>>strings.
>>s/one or more//
>>4.1.3 [[The UPnP enabled device must store Web Intents documents for
>the
>>Web
>>Intents Services the UPnP enabled device supports.]]
>>- "store" alone does not make it available to the UA. Change "store" to
>>"host" or "expose" or something else?
>>- Similarly with 4.1.4.
>>4.2 Step 2. [[If the action.webintents.org header is present and does
>>not
>>match the action attributes of the Services registered in the retrieved
>>Web
>>Intents document the UPnP enabled User Agent silently disregards the
>>discovered Service.]]
>>- It's unclear which Service is referred to in "disregards the
>>discovered
>>Service". I think this refers to a Web Intents service listed inside
>the
>>Web
>>Intents document, especially in cases where the Web Intents document
>>includes multiple services, and not all of them match the
>>action.webintents.org header. This, however, is a different use of
>>"disregards the discovered Service" as in the previous sentence, where
>>Service refers to the entire M-SEARCH response/UPnP service.
>>- Ideally, the UA may choose to register all services (for future use)
>>but
>>only present the matching one(s) in the picker. (see the next point.)
>>4.2 If a Web Intents document includes registration markup for multiple
>>services, does the UA register all the services or only the matching
>>service(s)? Step 4 implies the latter, but step 3 may be interpreted to
>>imply the former.
>>4.2.1 s/continously listen/continuously listen to/
>>4.2.2 [[...it is *assumed* that UPnP enabled User Agents that comply to
>>this
>>specification support Web Intents according to [WEBINTENTS]...]]
>>conflicts
>>with the Conformance section where [[A UPnP enabled User Agent *must*
>>support Web Intents [WEBINTENTS].]]
>>4.2.2 Why is UDA 1.1 referenced here while the rest of the document
>>refers
>>to UDA 1.0?
>>4.2.3 is non-normative but starts with a MUST statement.
>>A.4 The figure has a note [[To support more than one Web Intents
>Service,
>>add more service elements with different "serviceId" for the Web
>Intents
>>Services.]] In UPnP, multiple instances of a service is used when those
>>instances would have different state variable values, respond to
>actions
>>differently, etc. Since in this spec we already say that the state
>>variable
>>is dummy and there are no actions, there's no real reason to use
>>multiple
>>[UPnP] services. (Note that multiple Web Intents services can be
>>registered
>>with a single Web Intents document and therefore do not necessitate the
>>use
>>of multiple UPnP services.) I would suggest prohibiting the use of
>>multiple
>>UPnP WebIntents services altogether, which may make implementations
>>simpler.
>>This can be done at the beginning sentence of 4.1.1 [[The UPnP enabled
>>device must support the UPnP service which serviceType is
>>urn:schemas-webintents-org:service:WebIntents:1 ...]] - s/the UPnP
>>service/one UPnP service/
>>
>>This may well be a matter of personal preference. Instead of "UPnP-
>>enabled
>>device", I would suggest using either "Web Intents enabled UPnP device"
>>to
>>highlight the Web Intents capability of such devices, or simply UPnP
>>device
>>to be consistent with common usage. My preference is the former, as it
>>would
>>also help distinguish these more capable devices from "legacy" UPnP
>>devices
>>if/when we write new specifications to support those.
>>
>>- Cathy.

Received on Monday, 9 July 2012 08:25:10 UTC