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



-- 
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