RE: Representation consistency and content negotiation

Hello Drummond,

FWIW, here's my take on your questions...

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Drummond Reed
> Sent: 12 January 2009 08:13
> To: 'www-tag'
> Subject: Representation consistency and content negotiation
> 
> 
> At the risk of opening up a Pandora's box, some related questions have come
> up recently about which it would be good to get the TAG's view.
> 
> They are about the consistency of resource representations and the limits of
> content negotiation as discussed in AWWW [1].
> 
> A rule that OpenID folks, XRI TC folks, and others working on metadata
> discovery have been following since it was clarified for us last summer is
> that an http: or https: resource that responds to a GET request with a 2xx
> can return a representation of the resource in any content type it supports,
> BUT that representation SHOULD (or MUST?) be a consistent across content
> types.

Though not directly relevant to the question in hand, it may be worth noting that in general there is *no* prescribed relationship between the resources that are referenced by URI that differ only in scheme name. Specifically, http://example.com/ and https://example.com do not necessarily reference the same resource.

> For example, from the same URI it's okay to return versions of the same
> document in HTML, PDF, and plain text depending on the content type
> requested. But it's not okay to return a descriptor of the document (such as
> a POWDER or XRDS file) instead of the document itself.

Ok... one thing to sharpen the question is that whatever a URI reference with fragID refers to should be consistent across representations. It's ok that not all fragIDs resolve in all representations, but those that resolve in multiple representations should have a consistent interpretation of what is being referenced.

See http://www.w3.org/TR/webarch/#frag-coneg

> How does that rule apply in the following situations:
> 
> #1: Requestor-dependent representations. Many sites return different
> versions of a web page based on who is requesting it, such as 
> a personalized homepage. How does that fit with the rule? Is the cookie used 
> to identify the requestor considered implicitly part of the URI of the resource?

The way that I would (like to) tell the story is that the users credentials condition the view of the resource (state) that the user is allowed access to. 

Cookies shouldn't used as a means to identify say distinct shopping carts between users (though I'm sure it's done) - different resources should be blessed with different URI names.  So no, "...the cookie used to identify the requestor" should *not* be "...considered implicitly part of the URI of the resource." If you have distinct things that you want to be referencable by URI, then arrange for them to have distinct URI.

> #2: A related use case is requestor-dependent access control. For example is
> it okay for a request to the same URI to return a full web page for one
> fully-authorized requester and a redacted version to another
> less-fully-authorized requestor?

I say that that's ok if you can regard each of them as views of the same thing and that the convey a consistent if incomplete 'picture'.

> #3: Content type-dependent representations. Can the view of a resource
> returned from a URI as expressed by one content-type differ from the view
> expressed by a different content-type? For example, from the URI for a
> person's web calender, could a request for text/calendar (the ical content
> type) produce one response, while a request from the same URI for
> text/free-busy (a fictional free-busy content type) produce another?

I think that from a WebArch/naming POV what is important (as mentioned above) is that given a URI reference it is consistently used to refer to the same thing. Across content-types the resulting representations should be of the same resource (whatever is deemed to be the resource in question). Where the referring URI has fragIds that in some sense refer into the resource, then those fragID targets need to at least have a consistent referent across all the representation-types in which they resolve. It's ok for fragID not to resolve in some particular available representation.

I think the direct answer to your iCal example is that it depends on what you frame the resource as being. If you consider busy/free time as just a different (summary) view of your schedule and that the URI is a reference to your schedule then that's ok (I think - provided fragID 'semantics' are respected across representations). If you regard your busy/free time as a related, but distinct, resource from your schedule then connneg for the purposes of distinguishing the views is probably best avoided. Maybe think of it like this, if what you might want to say *about* the resource is dependent on which 'view' of it one is considering then you are probably thinking of multiple resources that have been accidentally conflated into one.

> 
> Thanks for any guidance.

Hope that helps,

> 
> =Drummond 
> 
> [1] http://www.w3.org/TR/2004/REC-webarch-20041215/

BR

Stuart

--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Monday, 12 January 2009 11:28:27 UTC