> 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
