OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Thanks as always for your detailed feedback, John. I believe I've incorporated
everything except for (6) below. The proposal then is to make the Link header a

From: John Arwe/Poughkeepsie/IBM@IBMUS

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

Here is what I have now:

    Consumers SHOULD inspect the response body for the Compact resource even if
    the Preference-Applied response header is missing. Some providers might
    omit the Preference-Applied header as discussed in [RFC7240].

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

Good catch. Some of the wording is left over from the previous version, which
claimed Compact was a representation rather than its own resource. (It's
debatable if that was ever really the case.)

>  "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 [...]

Here is what I have now:

    On responses to HTTP GET requests, Providers MAY include a Link header
    [RFC5988] for resources that support preview where

        - The context URI is the effective request URI,
        - The link relation is http://open-services.net/ns/oslc#Compact, and
        - The target URI is the URI of the Compact resource.

    The Link header allows providers to support preview for resources that have
    neither RDF nor JSON representations such as binary resources, although it
    can be used for any resource that supports preview.

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

I've added the following for creation. (Feedback welcome.)

    Providers MAY return a Link header in responses to newly-created resources

        - The context URI is the URI of the newly created resource,
        - The link relation is http://open-services.net/ns/oslc#Compact, and
        - The target URI is the URI of the Compact resource.

    This allows the consumers to discover the associated Compact resource URI
    without making additional requests.

    Example Request:

    POST /bugs HTTP/1.1
    HOST: example.com
    Content-Type: text/turtle
    Content-Length: 153

    @prefix dcterms: <http://purl.org/dc/terms/> .

    <>      a              <http://example.com/ns#Bug> ;
            dcterms:title  "Something went wrong" .

    Example Response:

    HTTP/1.1 201 Created
    Location: http://example.com/bugs/478
    Link: <http://example.com/bugs/478?compact>; rel="http://open-services.net/ns/oslc#Compact";,
          <http://www.w3.org/ns/ldp#Resource>; rel="type"
    Content-Length: 0

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

Sorry, I'm not clear on this...

Couldn't any ambiguity be cleared up by using an anchor on the Link header?

Samuel Padgett | IBM Rational | spadgett@us.ibm.com
Eclipse Lyo: Enabling tool integration with OSLC

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]