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
- From: Ian Green1 <ian.green@uk.ibm.com>
- To: Samuel Padgett <spadgett@us.ibm.com>
- Date: Fri, 16 Jan 2015 10:06:55 +0000
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]