Access conditions in DRs

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

Received on Thursday, 22 March 2007 13:44:32 UTC