TWO PROPOSALs involving Prefer

I tried to send this before my 'refactoring' message, but used the wrong 
address.  It is something I'd like to see in the spec before Last Call, 
unless someone finds a problem with it.  It's not a showstopper, though, 
since it can be done later, with only the cost of adding to the legacy 
support load.  It involves revising decisions made at the 
http://www.w3.org/2013/meeting/ldp/2014-01-27 meeting.   The proposal we 
adopted looked good at first, but I think this is better.

= brief intro =

Working on extensions to add to LDP, I keep coming up with cases where 
there's a Link header to another resource that you might want to use 
instead.

For example, I was thinking about how to determine if one has write 
access.  A simple, general solution would be to have a parallel version 
of a resource that acts like the real one except any changes made are 
lost, like this:
    Link: <sameResource?access-check=true> 
rel="http://www.w3.org/ns/ldp#noCommitVersion"

Or, how to provide an unchanging copy, if the server wants to:
    Link: <me?asOf=2014022309340102> 
rel="http://www.w3.org/ns/ldp#snapshotVersion"

There's a pattern here, where the client does HEAD, finds the right Link 
header, then does its GET on that.   It's basically the RESTful way to 
add a flag parameter.

= proposal 1 =

How about we generalize this as the client saying it would PREFER to 
save a round trip.  That is:

    Prefer: follow-link rel="http://www.w3.org/ns/ldp#snapshotVersion"

then, if the server chooses to do this, it will use the new 333/2xx 
return code, saying it's acting like you'd fetched whatever that link 
pointed to.

So a client who just wants the the first page, can say:

    Prefer: follow-link rel=first

or the last page:

    Prefer: follow-link rel=last

So, PROPOSAL-1 is to define Prefer: follow-link to save our clients some 
round trips.    It's nice, but doesn't really need to be in 1.0.   But 
read on:

= proposal 2 =

What if we consider the empty-container triples to be metadata, in 
addition to data.  That is, you can GET the container and see them mixed 
in with everything else, or you can follow the rel=meta link and just 
see them.

[ Um, wait.    Is it rel=meta or rel=describedby?      In 6.4.14 we say 
"rel=meta" and refer to RFC-5988.   But 5988 says nothing about 
rel=meta.  It has rel=describedby.   Simple bug in our spec? ]

The simple effect would be that instead of

    |Prefer: return=representation;
    include="http://www.w3.org/ns/ldp#PreferEmptyContainer"|

we'd have the somewhat simpler:

    Prefer: follow-link rel=meta

More generally, I think this would help in other ways.  It makes 
updating the empty-container triples easier, because you can just PUT or 
PATCH to them, without worrying about the membership triples changing at 
the same time.   It might make change notification and access control 
easier, since there's a clear way way to refer to the empty-contain 
triples separately.   It's a step toward allowing one set of clients 
access to to modify them but not another, etc.

So, PROPOSAL-2 is that empty-container triples MAY be available via a 
rel=describedby link header, and MUST be if the container is large 
enough to be paged.

I see two downsides to this proposal: (1) it doesn't work without 
333/2xx, and (2) it doesn't address the membership-triples vs 
containment-triples case.

I suggest addressing (1) by putting this at risk, and forking it to 
separate spec if necessary.   The only normative connection is to 
paging, which is already separated.

On (2), I guess leave in the return=representation thing for containment 
triples and membership triples, unless I can (in a separate thread) 
convince folks that we should get rid of that division anyway.

       -- Sandro