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: Martin P Pain <martinpain@uk.ibm.com>
- To: Jim Amsden <jamsden@us.ibm.com>
- Date: Tue, 12 May 2015 10:08:19 +0100
"
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>
"
I raised https://issues.oasis-open.org/browse/OSLCCORE-9
for looking at bootstrapping discovery.
In response to your comment in this email
jim, I added a comment there saying:
"
Jim said "Discovery is started with
OPTIONS on a (root) LDPC".
I don't like that, as it raises the question
"how do you find the root LDPC?"
The client most likely gets its first URL
from the user. The user is most likely to have a web UI URL to hand, and
ideally we won't force them to go looking for another one. This is the
train of thought I've tried to address in my
email
"
Kind
regards,
Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel |
|
Phone:
+44 (0)1962 815317 | Tie-Line:
37245317
E-mail: martinpain@uk.ibm.com
Find me on: and
within IBM on:
|
|
IBM United Kingdom Limited Registered in
England and Wales with number 741598 Registered office: PO Box 41, North
Harbour, Portsmouth, Hants. PO6 3AU
From:
Jim Amsden <jamsden@us.ibm.com>
To:
OASIS OSLC Core TC
Discussion List <oslc-core@lists.oasis-open.org>
Date:
04/05/2015 21:30
Subject:
RE: [oslc-core]
OSLC Core 3.0 Discovery
Sent by:
<oslc-core@lists.oasis-open.org>
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
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]