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: [oslc-core] Proposal to remove Link header option from Resource Preview spec


I agree with keeping the Link header as in the current draft. In fact, should we make the Link header a MUST?

The problem with Prefer is you can't discover whether there's a preview before requesting it. If the resource is a large binary file, you'll get the whole thing back if the server doesn't support preview. Implementing both methods shouldn't be too difficult for providers, but gives consumers more flexibility. This is especially important if the consumer has no idea what might be on the other side of a link.

I added the following for previews to the use cases and requirements document:


https://wiki.oasis-open.org/oslc-core/DelegatedUIUseCases#Previews_.2BAC8_Compact

Let me know if anyone disagrees.
--
Samuel Padgett | IBM Rational | spadgett@us.ibm.com
Eclipse Lyo: Enabling tool integration with OSLC


Inactive hide details for James Conallen---08/22/2014 11:41:55 AM---I agree.  It feels like we are creating proxy resources jusJames Conallen---08/22/2014 11:41:55 AM---I agree.  It feels like we are creating proxy resources just to enable type of preview request on no


    From:

James Conallen/Philadelphia/IBM@IBMUS

    To:

Steve K Speicher/Raleigh/IBM@IBMUS

    Cc:

Ian Green1 <ian.green@uk.ibm.com>, "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>, Samuel Padgett/Durham/IBM@IBMUS

    Date:

08/22/2014 11:41 AM

    Subject:

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

    Sent by:

<oslc-core@lists.oasis-open.org>




I agree.  It feels like we are creating proxy resources just to enable type of preview request on non-RDF resources.  As Ian said if we are saying that only RDF resources can have preview then what Sam proposes makes sense.  However if we want non-RDF resources to be preview-able, (and linkable), then we'll need to keep the link header option.

my 2c,



jim conallen
Rational Design Management (DM) Lead Architect, OSLC AM Lead
IBM Rational Software, IBM Software Group



Inactive hide details for Steve K Speicher---08/22/2014 11:27:28 AM---Thinking about Sam's suggestion, won't this have the probSteve K Speicher---08/22/2014 11:27:28 AM---Thinking about Sam's suggestion, won't this have the problem that you'll  get the Compact/Preview re

From:
Steve K Speicher/Raleigh/IBM@IBMUS
To:
Ian Green1 <ian.green@uk.ibm.com>,
Cc:
"OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>, Samuel Padgett/Durham/IBM@IBMUS
Date:
08/22/2014 11:27 AM
Subject:
Re: [oslc-core] Proposal to remove Link header option from Resource Preview spec
Sent by:
<oslc-core@lists.oasis-open.org>




Thinking about Sam's suggestion, won't this have the problem that you'll get the Compact/Preview resources for the associated RDF Source and NOT the binary?  For example, you can't have separate Compacts/Previews.  Maybe this is a feature but to Ian's requirement for non-RDF, it would seem that requiring someone to "mint" a new describedby resource and then produce RDF, then support prefer.
 

So taking Ian's requirement, probably best to stick with what already have (RDF property and Link header).  The Prefer can be seen as an optimization to remove the extra GET.  Clients probably should be warned that even though they say Prefer (and Accept: application/json), they still might receive a large JPEG for example.  Though, this is true with the 2.0 UI preview spec as well (or GET on any web resource).
 

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web ->
http://open-services.net 



From:        
Ian Green1 <ian.green@uk.ibm.com> 
To:        
Samuel Padgett/Durham/IBM@IBMUS 
Cc:        
"OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org> 
Date:        
08/22/2014 10:51 AM 
Subject:        
Re: [oslc-core] Proposal to remove Link header option from Resource Preview spec 
Sent by:        
<oslc-core@lists.oasis-open.org> 




Hi Sam,
 
Are you requiring that all resources for which I might want to supply a preview will be LDPRs? - that is, will deal with the type="describedby".   (I know I ought to know the answer to that but I've lost track!)
 

If so, then your suggestion seems better to me.
 

best wishes,
-ian

ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
IBM Rational
 

Samuel Padgett <spadgett@us.ibm.com> wrote on 22/08/2014 15:06:49:

> From: Samuel Padgett <spadgett@us.ibm.com>
 
> To: Ian Green1/UK/IBM@IBMGB
 
> Cc: "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
 
> Date: 22/08/2014 15:07
 
> Subject: Re: [oslc-core] Proposal to remove Link header option from
> Resource Preview spec
 
>
> Ian Green1 <ian.green@uk.ibm.com> wrote on 08/22/2014 09:04:51 AM:
>
> > Isn't there a requirement that I can discover the preview of a non-
> > RDF resource, for example, a binary?  Link header serves this purpose.
>
> Ian, this is a really good point and probably the easiest way to
> implement it.
>
> Another approach is to use an associated RDF source from LDP [1].
>
> Request:
>
>     HEAD /attachments/foo.gif
>     Host: example.com
>
> Response:
>
>     200 OK
>     Link: <
http://example.com/attachments/foo.rdf>; rel="describedby"
>     [other headers]
>
> then
>
> Request:
>
>     GET /attachments/foo.rdf
>     Host: example.com
>     Accept: application/json
>     Prefer: return=representation; include="
http://open-
> services.net/ns/core#PreferCompact"
>
> to get the Compact resource.
>
> The benefit of the second approach is that we don't have define a new
> Link relation. It's the same amount of HTTP requests.
>
> We're working on an OSLC Change Management attachments spec now, so it's
> timely feedback.
>
> [1]
http://www.w3.org/TR/ldp/#ldpc-post-createbinlinkmetahdr
> --
> Samuel Padgett | IBM Rational | spadgett@us.ibm.com
> Eclipse Lyo: Enabling tool integration with OSLC

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
 



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