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

I'm going to start addressing specific issues in the mailing list in addition to capturing them in JIRA. I'm doing this for two reasons: 1. to involve more OSLC Core and Domain TC, and other OASIS members who may not have access to our JIRA issues list, and 2. to get faster turnaround on the proposed resolutions.

If at all possible I'm going to attempt to present the issues with proposed resolutions, and indicate that if there are no objections, this is what I will be editing into the documents. We can flag anything that needs further discussion, or a TC vote in order to proceed, and I'll either delay making those changes, revert them, or update them as needed. Quick responses will hopefully avoid unnecessary conflicts or document revisions.

The reason for this approach is that we have September as the target for TC vote to submit OSLC Core 3.0 for public review. I order to make that date, with all the changes resulting from the 2.0 compatibility decision, we've go to pick the pace up a bit.

The first installment is on Attachments.

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.

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.

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data

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