Attachments resolutions

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

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
919-525-6575