Re: Fw: [oslc-core] Proposal to remove Link header option from Resource Preview spec

[John Arwe <johnarwe@us.ibm.com>]

> Do we need to flip it or is this OK? 

No; the syntax always looks backwards to me too.  It
might help your mental model to read the "context URI" part of
5988.  Or it might just hurt your head; but basically the default
context (subject) URI is the effective request URI; the link target (object)
URI is the first thing after the Link: header name; the rel= value (predicate)
comes last in this syntax.

> Should it be lower case "compact"?

Matter of opinion.  I tend to capitalize
when it's a concept I expect there to be refinements of (so it's rdfs:Class-like,
and I use the convention that classes begin with capital), and not capitalize
when I think it's a terminal ("true" individual term, so not
obviously class-like, so use the convention for predicates and other not-class
things).  Others care less, more, or not at all.



"Including a Preference-Applied
response header with value return=representation is OPTIONAL" ...
that is true, but it is true b/c RFC 7240 says it's optional, so optional
should not be "rendered normatively" here and a citation link
would normally be included (in W3C style, IIRC OSLC style was a bit looser
about citations in restated text, not sure what we intend to do in OASIS
style).

" Providers SHOULD provide Compact
representations ... had the Consumer instead requested the default representation
" need scrubbing.  They were never different representations
of the same resource (HTTP hat on), they were (and I think still are, but
whatever) representations of "very closely related" but distinct
(HTTP) resources.

"Providers MAY also provide a Link response header [[RFC5988]] with target URI of the Compact resource and rel value http://open-services.net/ns/oslc#Compact on HTTP GET, HEAD, and OPTIONS requests for resources that support preview, but don't have RDF or JSON representations."

95% right; quibbles

1: some readers will think this means they should/must not provide the link on other methods (silence implies different things to different audiences).  I don't see any need to limit it; maybe make these exemplary.  If you're feeling minimalist, also drop it down to GET only; get gives you HEAD implicitly, "nobody" uses OPTIONS anyway, and OPTIONS would be allowed (along with PUT, POST, ...) by making whatever we do mention exemplary.

2: to be really complete, should say talk about the context URI; you'd want the default (the effective request URI) on the methods you cited above.  

3: If we wanted a create responses to support this (seems reasonable, and mentionable), the context URI there would be the same as the Location header (URI of the newly created resource).  Obligatory note from 5988 on that: when the context URI != the recipient has to trust the server to make assertions about the context URI; this is usually true for us, but if POST (Create) to rtc9-foo.tivlab.ibm.com created a resource on rtc-master.ibm.com, it's less obvious.  I'd just point to 5988 and minimize any restatement.

4: the rdf/json part is ambiguous.  should I read it !(rdf|json) or as !rdf|!json?

5: It's not obvious that we need to limit it by media type; the spec heading didn't suggest to me that it applied to anything other than all resources.  It would be completely fair to assert (1) some clients (RDF-aware ones, possibly JSON-aware ones) are likely to prefer it in the content, other clients (those agnostic to media type) are likely to prefer it in the header, and (2) for some media types the header might be the only "sensible"/possible choice... while many formats support encoding of name/value pairs in the content, not all do.

6: Given that clients have 2 ways to expose the preview URI, is there guidance (here or elsewhere) about when to use one vs the other?  If not, might be simpler to say "if preview is supported, MUST..."; given the constraints, must-header is the only one that flies for all resources; let it be that the advantage of some media types (like RDF) is that you can get the contents without a HTTP retrieval operation, as a convenience to clients capable of understanding those media types, but you can Always get the link itself via the Link header.  There's no harm in also providing it in the content, but it's redundant.

7: on ++responses to++ HTTP GET, HEAD, and OPTIONS requests , and then remove "response" before header in the first part.  Link is NOT actually defined strictly as a response header, and LDP (at least) uses it on requests as well.

Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead