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


Hi Sam -
Thanks Sam.  I've created a review register at https://wiki.oasis-open.org/oslc-core/Attachment30Review.   I will keep this up to date as issues are closed etc.  Suggest we keep the discussion to the mailing list?

Comments below.

best wishes,
   -ian

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


<oslc-core@lists.oasis-open.org> wrote on 14/01/2015 19:58:10:

> From: Samuel Padgett <spadgett@us.ibm.com>

> To: Arnaud Le Hors <lehors@us.ibm.com>
> Cc: Ian Green1/UK/IBM@IBMGB, "OASIS OSLC Core TC Discussion List"
> <oslc-core@lists.oasis-open.org>, Steve K Speicher <sspeiche@us.ibm.com>

> Date: 14/01/2015 19:58
> Subject: Re: [oslc-core] Review comments on Attachments 3.0 draft
> Sent by: <oslc-core@lists.oasis-open.org>
>
> 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.


I don't see this when I read the LDP spec (4.4.1.2).  Where should I look?  4.4.1.2 describes that a server MAY indicate in Link header that an "exposed" resource is non-RDF. "Exposed" is a bit vague but I wouldn't assume it extends to a client POSTing an entity. In addition, there is vagueness of whether the MAY refers to the use of the Link header, or whether it refers to the acceptance of non-RDF formats. @Steve: Can you clarify this LDP part, please? OPEN.  

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


ACCEPTED


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


okay, that's fine.  CLOSED.

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


examples are in section 8 whilst 7 and 9 are normative. OPEN.

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


okay. so it is meant "MUST be LDP 1.0 compliant"?  OPEN.

>
> > 7.1.1. what is an Attachment server?
>
> Fair question. Is "servers that support attachments" better?


yes. :-) ACCEPTED.

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


yes, this is what I understood.  My question is why make this constraint? A server should be free to organize its attachments/resources as it sees fit.  What is lost by allowing, for example, two resource to share an attachment container?  OPEN

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


okay.  CLOSED.

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


i would prefer to keep the terms separate, if that is acceptable and there are no arguments against.  Maybe a topic for the TC to discuss via email?  OPEN.

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


Remove it or make it non-normative?  ACCEPTED.

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


My question is how a server would do 7.2.3 - a resource indicate in its representation the oslc:AttachmentContainer(s) that can be used to make attachments to that resource.  What vocabulary term would link the resource to the container?  OPEN.

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


ACCEPTED.

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


not sure this is yet closed.  leaving OPEN

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


okay. OPEN

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


seems fine.  ACCEPTED.

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


suggest we discuss this one at the TC?  OPEN.

>
> > 7.3.6 Standard HTTP. I don't see this need to be in this document.
>
> I think that's fair.


ACCEPTED.

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


ACCEPTED

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


okay. CLOSED

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

ACCEPTED

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


We express cardinality constraints using resource shape.  But here, there is no resource whose shape is being defined - you are trying to impose a cardinality constraint on the generic use of a property.  This doesn't mean anything.  We need to find another way to express the invariant.  OPEN

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


understood.  But, the title of the attachment is subject to special processing (Slug handling). A server MAY ignore a Slug or it may alter the Slug value.  I was looking to clarify whether or not the server can take the same liberties on a PUT of a new title.  OPEN.
>
> > 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.


it would be useful for applications that support query over resources.  Such a type would allow selection of attachment containers by querying for that type.  I don't know this to be an important use case.  We could define this type but make its use in representations OPTIONAL.  OPEN.

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

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]