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


Resending to fix the formatting (apologies).

Review of
[http://tools.oasis-open.org/version-control/browse/wsvn/oslc](http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/specs/attachments-v3.html)-
[core/specs/attachments-v3.html](http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/specs/attachments-v3.html)

Review by ian green (oslc core tc). SVN rev 82.

> 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.

- Sam



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