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] Review comments on Attachments 3.0 draft


Ian, thanks. Really appreciate your feedback. Here are my responses.

Question on scope: Is it the case that any LDPR can be an
attachment? 7.3.1 currently states that an attachment MUST be an LDP-NR,
and my understanding of LDP is that this means that an attachment would
not be allowed if it were, say, application/rdf+xml.

Even application/rdf+xml can be treated as an LDP-NR if created with the
appropriate interaction model when creating the attachment. This is done
with the HTTP Link header (as defined in LDP). So I think we're covered?

Suggestion: in section 5 which is declared non-normative, there are
what look like normative statements. I suggest rewording to remove any
normative statements and try to bring out the role of an attachment
descriptor and its connection with an attachment - the idea is that an
attachment descriptor describes the size, media type and title of the
attachment, and that there is a way of taking the POST and building such
a descriptor from that.

Thanks, yes, this needs updating. It is not meant to be normative. The
introductory sections need work.

oslc:AttachmentContainer doesn't seem to be definned as a vocabulary
term (its in the turtle, but not in section 9). I wasn't sure why.

There are no special properties on it, so we don't have a shape. It is
defined as an RDF class here:

https://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/specs/attachments-v3.html?sc=1#AttachmentContainer

I think the examples should come after the normative content which
denes the terms appearing in those examples.

OK, how it's currently structured then?

7.1.1 "at least" seems redundant and/or I don't think defined
anywhere.

The intent is that it could be a LDP 1.1 or 2.0 compliant as well.

7.1.1. what is an Attachment server?

Fair question. Is "servers that support attachments" better?

7.2.1 holds attachments for only that resource - why is this
necessary?

The requirement is trying to say that there isn't just one big container
of all attachments for all resources on server. In other words, all
attachments in this specific container are for only this resource.

In the case there is more than one attachment container on
the resource, this spec is silent on how a client would work out which
to use (that's ok, but what is the use case for more than one?)

Well, I know at least one application can have multiple attachment
fields on a single record (Rational ClearQuest). The idea is that it
could be supported through the spec, although how the client works it
out is not specified.

7.2.2 Why is http://open-services.net/ns/core\#AttachmentContainer used
here when that term is also an rdf:type? Shouldn't this be a distinct
term, say http://open-services.net/ns/core\#attachmentContainer

I'm open to your suggestion. I'm not sure there is a convention for link
relations. It would mean that we define an additional URI, which is OK.

7.2.3 Why is this in the spec? We might want to additionally constrain
the representations of those LDP-RS resources which have attachment
containers so as to ensure that the HTTP header and and triples in the
representation are in agreement (same containers), but I don't see the
need to have this clause otherwise.

I guess it is more a hint to implementations that they can do this,
which might save some HTTP requests. I am OK taking it out.

7.2.3 How would this be done? I was expecting a property (not a class)
http://open- services.net/ns/core\#attachmentContainer. This term would
need to be included in the vocabulary.

See example 8.6. The attachment container points to the resource using
ldp:membershipResource following the direct container membership triple
pattern.

7.2.2 suggest rewording so make clear there MUST be a Link for each and
every AttachmentContainer associated with the resource (as permitted
in 7.2.1) . Not sure if need to say anything about ordering of those
Link headers.

Agreed.

7.3.1 See question above on scope. I think this ought to be
generalized to LDPR.

See my answer above.

7.3.2 Is this necessary, and is it even correct? What about a server
that needs to do a redirect, for example?

I guess I see "successful responses" as being 2xx responses. Redirects
should still be OK? Let me think about this.

7.3.3 suggest rewording to cover PUT case: "from an HTTP POST request
that created the attachment, or the most recent HTTP PUT which changed
the attachment". I wonder if this is obvious to the point it doesn't
need to be stated?

So remove the sentence "This is often the Content-Type..." I'm fine with
that.

7.3.4 Is there a reason this is not a SHOULD?

I am fine either way. I chose MAY because I didn't think it was too
important.

7.3.6 Standard HTTP. I don't see this need to be in this document.

I think that's fair.

7.3.9 Standard HTTP. I don't see the need to be in this document.

This one is more debatable. A lot of clients might try to simply remove
the triple from the container instead of calling HTTP DELETE on the
attachment URI. Since there are multiple ways you might try to delete
the attachment, I think we should talk about it somewhere in the spec. I
can't recall off-hand what LDP says about removing containment or
membership triples. Maybe Arnaud or Steve can better comment.

7.4.2 StandardLDP-C. I don't see the need to be in normative section
of this document. I would think this would be in the basic outline
section.

Fair.

7.4.4 If a client violates the Slug header SHOULD NOT include an
extension what happens? What happens when there is more than one Slug?

Unspecified, which I think is OK? I would defer to RFC 5023, except it's
not covered there either.

7.5.4 This is ambiguous since a client-supplied Slug, according to
section 7.4, may be absent, ignored or altered by the server. I think a
simple rewording which is that the dcterms:title should be whatever the
server chooses, informed by the client-supplied Slug, if any.

Agreed.

9. Is this spec trying to restrict the way in which wdrs:describedBy
can be used when the object is an AttachmentDescriptor? The cardinality
restriction doesn't apply to the object of links. Instead, the spec
needs to state the relationship between a attachment and its descriptor
(each descriptor describes exactly one attachment) and an attachment
has at most one descriptor. The relation between these resources is
represented using describedBy. I don't see why describedBy is described
as an inverse property (inverse of what?) it is just a link between two
resources.

It's inverse meaning that it's not a property for
AttachmentDescriptor. Rather, AttachmentDescriptor is the object of an
wdrs:describedBy triple. (The subject is the attachment as in 8.6).

9. Are there any restrictions (eg as in 7.4.4) that restrict the
dcterms:title of an attachment descriptor? Can a server accept
a change to dcterms:title and alter it as it does when a client
supplies a Slug?

The intent is that you can do a PUT on the AttachmentDescriptor to
update a title. I'm not sure if it's explicitly stated in the spec.

9. I think http://open-services.net/ns/core\#AttachmentContainer
should be definned in this section (and as I have suggest above),
http://open-services.net/ns/core\#attachmentContainer.

I was actually considering removing the AttachmentContainer class. I'm
not sure it's necessary. We can simply use the LDP container types.

-- 
Samuel Padgett | IBM Rational | spadgett@us.ibm.com
Eclipse Lyo: Enabling tool integration with OSLC


-----<oslc-core@lists.oasis-open.org> wrote: -----To: Arnaud Le Hors/Cupertino/IBM@IBMUS
From: Ian Green1 
Sent by: 
Date: 01/13/2015 05:52AM
Cc: "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>, Steve K Speicher/Raleigh/IBM@IBMUS, Samuel Padgett/Durham/IBM@IBMUS
Subject: [oslc-core] Review comments on Attachments 3.0 draft

Hi Arnaud

I have reviewed the Attachments 3.0
spec - ironically enough, attached. If there is some process around review
findings (eg where to put them etc.) let me know.







@Sam,Steve: let me know if you would
like to go over these on a call.



best wishes,

   -ian



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

IBM Rational

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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php ;

[attachment "img_review_of_attachments_v3.pdf" removed by Samuel Padgett/Durham/IBM]



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