W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

[widgets] <access> element

From: David Rogers <david.rogers@omtp.org>
Date: Thu, 23 Apr 2009 13:58:50 +0100
Message-ID: <4C83800CE03F754ABA6BA928A6D94A06019C489E@exch-be14.exchange.local>
To: "Web Applications Working Group WG" <public-webapps@w3.org>
Dear all,


Please find below some input from the OMTP membership for the <access>
element discussion. Overall, the functionality provided does what we
want. It is just about as simple as it can be, which is good. There is
functionality in here that we did not have with <target> - such as the
ability to specify a path and query string - but that's OK.


The current draft really doesn't say very much about what the consuming
User Agent is supposed to do with the information; it says syntactically
what is valid but hardly anything about the processing. OMTP propose to
have some text to cover this such as:


* Each <access> element that includes a uri attribute defines a set of
target IRIs.

* The set of target IRIs for the Widget is the union of all of the
target IRIs defined by each <access> element.

* The User Agent SHALL prevent any network access by the Widget, by any
method*, to an IRI that does not belong to the set of target IRIs.

* The User Agent's security policy MAY prevent network access by the
Widget to an IRI that does belong to the set of target IRIs.


Note: * "by any method" is a bit weak and it might be necessary to be
explicit about what this means. It at least should cover programmatic
access (such as by XHR) and network access triggered by the processing
of specific DOM element.


The drafting could do with tidying in some places, e.g.:

* ".. the host ... must be granted access to ..". Apart from being
grammatically broken, OMTP think it is better to have a precise
definition of the set of target IRIs, and then have a separate statement
about what membership of that set signifies.
* Similar comment with "lower-level domains". There should be something
explicit about it meaning sub domains at arbitrary depth from the
specified domain.
* It should explicitly say that using the wildcard character in any
position other than the first character in a domain specifier is
invalid. I.e. it's not intended to be a general glob expression as in







David Rogers
OMTP Director of External Relations 

Received on Thursday, 23 April 2009 12:59:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC