oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [oslc-core] OSLC Core 3.0 Discovery
- From: Jim Amsden <jamsden@us.ibm.com>
- To: OASIS OSLC Core TC Discussion List <oslc-core@lists.oasis-open.org>
- Date: Mon, 4 May 2015 16:30:36 -0400
Martin,
Responses to you comments embedded below...
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From:
"Sarabura, Martin"
<msarabura@ptc.com>
To:
Jim Amsden/Raleigh/IBM@IBMUS,
OASIS OSLC Core TC Discussion List <oslc-core@lists.oasis-open.org>
Date:
04/28/2015 03:36 PM
Subject:
RE: [oslc-core]
OSLC Core 3.0 Discovery
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...
Martin Sarabura
R&D Fellow, PTC
From: oslc-core@lists.oasis-open.org
[mailto:oslc-core@lists.oasis-open.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
TC members,
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.
<jra>I took them off as this is
for noting the current editor and neither of them are participating in
the TC any longer</jra>
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.
<jra>Discovery is started with
OPTIONS on a (root) LDPC.</jra>
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..."
<jra>That was suppose to say Although
a client may not know....</jra>
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"
<jra>Used your language</jra>
[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.
<jra>Done. I moved the examples
into different sections, this removed a redundant example.</jra>
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.
<jra>Fixed</jra>
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.
<jra>Done</jra>
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
919-525-6575
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]