Re: [oslc-core] Attachments resolutions

["Jim Amsden" <jamsden@us.ibm.com>]

Ok, I found the discussion at: https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2015.01.22.
This is related to LDP 1.0, section 5.2.3.4 where LDP defines the interaction
models for POSTing to LDPCs and LDPRs. The reason the Attachment spec has
this requirement and special case is because the AttachmentContainer is
an LDPC and therefore must follow the LDPC interaction model when posting
an attachment. The special case provides a different interaction model
to allot POSTing an LDP-NR to the AttachmentContainer LDPC.

So this issue can be resolved.


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:      
 Martin P Pain <martinpain@uk.ibm.com>
To:      
 Jim Amsden/Raleigh/IBM@IBMUS
Cc:      
 "OASIS OSLC Core
TC Discussion List (oslc-core@lists.oasis-open.org)" <oslc-core@lists.oasis-open.org>
Date:      
 07/23/2015 12:02 PM
Subject:    
   Re: [oslc-core]
Attachments resolutions
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

See responses inline

Kind regards,

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel

Phone:+44 (0)1962 815317 | Tie-Line:37245317 E-mail: martinpain@uk.ibm.com Find me on:  and within IBM on:

IBM United Kingdom Limited Registered in England and Wales with number
741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants.
PO6 3AU 

<oslc-core@lists.oasis-open.org> wrote on 22/07/2015 22:08:25:

> From: "Jim Amsden" <jamsden@us.ibm.com>
> To: "OASIS OSLC Core TC Discussion List (oslc-core@lists.oasis-
> open.org)" <oslc-core@lists.oasis-open.org>
> Date: 22/07/2015 22:10 
> Subject: [oslc-core] Attachments resolutions
> Sent by: <oslc-core@lists.oasis-open.org>
> 
...
> 
> 1. AttachmentDescriptor has a property attachmentSize although a 
> client could also use HEAD on an attachment URI to get the same 
> information. This is redundant data that servers have to update when
> executing a PUT or POST to update or create an attachment. I'm not
> sure what the purpose of this property is - perhaps to help clients
> avoid extra HEAD requests to determine if they are able to deal with
> potentially large attachments, or to provide size information for
> display purposes when presenting a list of attachments for selection.
> 
> Resolution: Unless there are objections - we'll keep this property
> as is and servers will have to manage the redundancy.

MP: As it's zero-or-one, servers can omit it if it causes difficulties.
However, 7.3.4 should probably be updated to say "if present"
or "if they exist" to explicitly allow for the case of it being
omitted. 


> 
> 2.  Attachments are required to be NonRDFSource or LDP-NR resources.
> I'm not sure why, but its probably because an LDP server should be
> supporting RDF resources in LDPCs, not as attachments. However there
> is a clause that defines a special LDP-NR interaction mode that uses
> a Link header to override the rule and tell the server that an RDF
> resource isn't really an RDF resource for attachment purposes. This
> appears to be an escape clause to allow attachments to be RDF 
> resources, even though that's not common practice.
> 
> Discussion: We could 1) remove the restriction that attachments have
> to be LDP-NR resources (then the special case isn't needed), 2) 
> remove the special case and not allow RDF resources to be 
> attachments - thereby following our own rules or 3) leaving it as
it is. 
> 
> Resolution: I recommend removing the restriction that attachments
> have to be LDP-NR resources. The reason is that any resource that
> supports attachments has a related AttachmentContainer accessed 
> through a Link header on the resource. This is an LDPC. An LDPC can
> contain any resource type, including RDFSource - so why make the 
> restriction? Treat AttachmentContainer like any other LDPC from the
> client and server's standpoint and attach whatever resources you want
there.
> 

MP: I can't say I've paid a lot of attention to the attachments work, but
I can't remember the reason for the restriction. Is there anything in the
email archives about it?

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