- From: Phil Archer <parcher@icra.org>
- Date: Thu, 22 Mar 2007 12:32:55 +0000
- To: Public POWDER <public-powderwg@w3.org>
I wanted to bring a discussion going on within the group onto the public list (comments please!) Description Resources will be able to describe a group of things, primarily online resources delivered as a stream of bytes over the Internet. So, for example, a DR might say that "all documents on example.org are in Spanish." What if the client includes an HTTP Accept-Language header for French? Typically that's what it will receive if the resource at the given URI is available in that language - so what the DR should perhaps say is that the resource is available in French or Spanish. But if it does that, then it probably should also declare what the default language is. This goes to the heart of the resource grouping issue that, as soon to be reported in the meeting summary for 19 March [1], the WG has resolved to begin working on first. Should the definition of a group of resources support conditions such as "if the HTTP Request Headers include xyz?" Probably yes (the strawman in [2] has a place holder for this), but maybe user preferences, as encoded in cookies, will override such behaviour. Even with a simple example we quickly reach a very complex statement such as "All resources on example.com will be delivered in French if accessed with the appropriate HTTP Language-Accept header unless overridden by a cookie. The default language is Spanish." One can readily concoct yet more sophisticated examples and it starts to look unwieldy but is complexity inevitable and, even if it is, would it be right to limit the expressivity of DRs to prevent complexity developing? The use cases [3] behind the work are much simpler and unlikely to generate convoluted data – and you can't predict how people will use a given system. Furthermore, DRs as envisaged in the strawman have a method to minimise complexity by using a package. The French/Spanish example could be encoded as follows: <Package> scope: example.org Ordered list of DRs – a given resource on example.org is described by the first DR to match the condition. 1. All resources on example.org are in French if a cookie is present to indicate this preference. 2. All resources on example.org are in French if an HTTP Language-Accept header indicates this preference 3. All resources on example.org are in Spanish. </Package> Thus we break the situation down into manageable chunks. What seems to be emerging from the discussion is that the definition of a group will need to support: 1. Matching a URI against patterns 2. Properties of resources, perhaps, but not necessarily, with reference to an external data source (so in some cases you may have to fetch a resource to determine whether or not it is in the group). 3. Listing 4. Access criteria All these to support negation (i.e. any URI NOT matching a pattern etc) The problem this approach raises is that there is a DR in there that says "all resources on example.org are in Spanish" which is not true unless the other DRs are false. Therefore it MUST NOT be processed in isolation. Now that's challenge... Phil [1] http://www.w3.org/2007/powder/blog [2] http://www.w3.org/2007/powder/History [3] http://www.w3.org/2005/Incubator/wcl/XGR-wcl/Overview.html#appendix1 -- Phil Archer Chief Technical Officer, Family Online Safety Institute w. http://www.fosi.org/people/philarcher/
Received on Thursday, 22 March 2007 12:33:12 UTC