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 Saturday, 7 July 2012 09:45:45 UTC