Jim, it's not just OK - it's a really good idea to send out your proposals in this manner to give members a chance to raise possible issues that should be addressed
at the next meeting.
I have provided input on some of these questions, see inline below...
R&D Fellow, PTC
From: email@example.com [mailto:firstname.lastname@example.org]
On Behalf Of Jim Amsden
Sent: April-22-15 3:06 PM
To: OASIS OSLC Core TC Discussion List
Subject: [oslc-core] OSLC Core 3.0 Discovery
Find attached my updates to discovery.html. Since this is my first non-trivial contribution, I have not checked in any changes. I'm not sure what the review procedure is for merging and checking
in, but wanted to get this out for quick review.
Here's what's covered in the changes, and any remaining questions I had:
1. Should Steve and Sam continue to be listed as editors even though they are likely no longer active given their contribution to the content?
[martin] Probably OK to leave them on as editors until somebody else picks up the task of making new edits.
2. TODO: in Conformance section needs to be completed with Discovery specific conformance. For example, are all OSLC Core 3.0 servers required to support discovery? I added some statements regarding conformance.
[martin] You mentioned this at the last meeting and I think it's an important question for all of our members to consider. Personally I agree. If you're
not going to support discovery then how much better than simple REST are you? There is still a bootstrapping issue - where do you start your discovery? I'm still not clear on that.
2. Updated introduction and motivation sections with more descriptive text. Changed the titles of the sections to be more descriptive and consistent.
[martin] It's better. One thing in Motivation, I'm having trouble parsing the middle clause of sentence "Although a client would now know ahead of time..."
3. Section 5.2 Resource Creation Discovery - "The existence of an Accept-Post header on an HTTP response to a given Request-URI
will indicate that both an HTTP POST is accepted for authorized requests and which content types are support in the entity body of an HTTP POST request". Should the will be MUST? There are numerous examples of this.
[martin] The wording is a bit cumbersome because the existence of the header indicates two things, not one. So the word "will" creeps into the wrong place,
in my assessment. Perhaps something like "The existence of an Accept-Post header on an HTTP response to a given Request-URI indicates i) that an HTTP POST will be accepted for authorized requests and ii) what types of content are supported in the entity body
of the HTTP POST request"
[martin] The example between normative sections 5.2.3 and 5.2.4 is non-normative. It should be labelled as such. Similarly between 5.3.1 and 5.3.2.
4. Section 5.3 Checking for constraints for creation - RECOMMENDS Resource Shapes which are not part of LDP. Is there any issue with a RECOMMENDATION in an OASIS specification referring to non-OASIS specifications such as the open-services.net OSLC 2.0 Resource
Shapes. I think this is OK, just checking.
[martin] BTW the URI to the "bug" specs are in example.com in example 4 and open-services.net in Example 1. We should probably be consistent.. Also, Example
2 refers to example.come instead of example.com. Also typo after example 2: createionType instead of creationType.
5. If an LDP container supports many resource creationTypes, and some of them are constrained and others are not, how are the link headers for the creationType correlated with the constrainedBy link headers?
The Link header with an appropriate context URI, a link relation of
http://www.w3.org/ns/ldp#constrainedBy, and a target URI identifying a set of constraints would be returned in response to a failed POST or PUT to a resource that violated the constraint.
These link headers may be included in the OPTIONS on the LDP container as well. If the container supports multiple resources, then should the constrainedBy relations include context IRIs (anchor parameter) to identify the resource type that is being constrained?
[martin] Ugh. Yeah, this requires clarification... These are valid issues.
If an LDPC supports creation of more than one creationType, is a Link header with rel=“type” or rel="http://open-services.net/ns/core#creationType creationType" required on the POST to indicate which
type of resource should be created?
http://www.w3.org/TR/ldp/#ldpc-HTTP_POST doesn’t say this since its not really applicable to RDF resources since they would already specify their rdf:type and non-RDF resources would likely use MIME types. The Accept-Post header isn’t enough since the
same content type could apply to different resource types. Content type is the format of the content, not its type.
Section 7.1.2 creationType seems to indicate that this could be used on a Link-relation rel value for POST, but it seem like this should be explicitly specified.
6. Added HTTPS Basic as required minimum authentication and OAuth2 as SHOULD.
[martin] Recommend you remove the prefix "At a minimum, " because if you're going to say MAY then there is no minimum. Also, I believe the hyperlinks
to OAuth2 and OpenID Connect should be anchor references to the list in Section D.
7. How does http://open-services.net/ns/core#creationType relate to rdf:type? Should both be supported?
[martin] At the very least we should indicate how to resolve the rdf: namespace, right? http://www.w3.org/1999/02/22-rdf-syntax-ns#
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data