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: [OASIS Issue Tracker] (OSLCCORE-6) How does POST to an LDPC that supports multiple creationTypes indicate which resource to create?


    [ https://issues.oasis-open.org/browse/OSLCCORE-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59510#comment-59510 ] 

Martin Pain  commented on OSLCCORE-6:
-------------------------------------

Issue 2:
I'm not particularly familiar with resource shapes. I presume they can include an rdf:type value that is required on the resource that is (in this case) being created? If so, that would tie each constrainedBy constraint to a creationType, although admittedly with the downside of potentially having to GET all of them to find out if there is a constraint for the given type.

To add an anchor on to the constrainedBy Link header seems wrong to me. It seems like including this:
Link: shape-URI; rel="...#constrainedBy"; anchor="type-URI"
would be saying:
"[In all contexts] the RDF type type-URI is constrained by the shape at shape-URI"

whereas this:
Link: shape-URI; rel="...#constrainedBy"
would be saying:
"[POSTS on] this LDPC are constrained by the shape at shape-URI" (where the shape may or may not only describe a single type).

The latter is more correct, as it is the LDPC (or, more accurately, POSTs on it) that are constrained. Putting the anchor on the type seems to be making a statement about the type itself outside the context of this LDPC.

That is, by setting the anchor parameter, it seems to me that it is telling the client to ignore the context in which the Link header was specified when interpreting its meaning - instead taking the given anchor URI as the context (except when determining whether to trust it, but I don't think that's relevant here) - therefore making a statement about the type itself not about its usage in this particular LDPC. If I've misunderstood the anchor parameter, please correct me.

Alternatives to using anchor:

1. Just let the shapes say which type they constrain. Clients who really care can GET all of them (unlikely to be a huge number of shapes, I expect). I suggest most clients won't care about checking the constraints, and can just POST anyway, and let the server return an HTTP error code (with the correct single constrainedBy Link header, as specified by LDP IIRC).
2. Alternatively, we could say that if you have more than one creationType then you can have at most one constrainedBy link, which must only point to a document that maps type URIs to shape URIs (i.e. to other constraint documents, of whatever format). Then you only have a single GET which tells you which types are constrained by which shapes.


> How does POST to an LDPC that supports multiple creationTypes indicate which resource to create?
> ------------------------------------------------------------------------------------------------
>
>                 Key: OSLCCORE-6
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-6
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Task
>            Reporter: James Amsden
>            Assignee: James Amsden
>
> An OPTIONS request on an LDPC could return multiple Link: headers with rel="http://open-services.net/ns/core#creationType"; indicating the container can support multiple resource types. The Accept-Post header indicates the entity request body format, but does not specify the resource type expressed by that content. RDF resources could specify their type directly in an assertion, but this is not available for LDP-NR (Non-RDF) sources. 
> Section A.1.2 creationType seems to indicate that this could be used on a Link-relation rel value for POST, but this should be explicitly specified and have an example.
> A related issue is that an HTTP OPTIONS request on an LDPC can also return multiple Link: headers with rel="http://www.w3.org/ns/ldp#constrainedBy";. A POST or PUT to create or update a resource can use return this header when the request fails because of violation of the constraint. But there is currently no way to associate multiple creationType and constrainedBy link relations for an LDPC. The constraindBy link may need to include a context IRI (anchor parameter) to identify the resource type that is being constrained.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


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