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] Attachments resolutions

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
Find me on:
LinkedIn: http://www.linkedin.com/profile/view?id=99869908 and within IBM on: IBM Connections: https://w3-connections.ibm.com/profiles/html/profileView.do?userid=12c849c0-ddd5-1030-9b5f-d70a3a891 

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

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