RE: Representation consistency and content negotiation

Stuart, thanks very much - your answers are illuminating. See inline.

> -----Original Message-----
> From: Williams, Stuart (HP Labs, Bristol) [mailto:skw@hp.com]
> Sent: Monday, January 12, 2009 3:24 AM
> To: Drummond Reed; 'www-tag'
> Subject: 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.

Yes, I'm clear on that. Interestingly, this is one identification issue that
XRI 3.0 will tackle with its XRI-as-relative-URI architecture
(http://wiki.oasis-open.org/xri/XriAsRelativeUri). The semantics of
XRIs-within-URIs will allow the same resource to be identified across
multiple URI schemes.

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

Thanks for that reference. I was aware of it but didn't realize how much of
a bearing it has on my question. To take a graph view of it (with XDI I have
graphs on the brain ;-), what you're saying is that the graph of information
associated with a resource must be consistent -- that's why fragIDs should
resolve consistently across representations.

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

I understand. Ironically I'd guess that 90+% of the shopping carts out there
have the same URI and just use cookies to differentiate customers. I guess
they are taking the approach that each customer represents a different state
of the cart.

> > #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'.

Yes, that makes sense.

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

So to summarize what you are staying: two content types could return
different subsets of information about the same resource as long as those
subsets are subsets of a consistent graph of information about the resource,
but if the content type requested changes the graphs of information returned
to a different, not-consistent graphs, that's where you should clearly use
different URIs.

That seems like a clear rule. (Talking in graphs always seems to help clear
these things up for me.)

Best,

=Drummond

Received on Monday, 12 January 2009 18:06:54 UTC