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: Re: Links from LDPCs to dialogs in RDF, XML, compact resource, etc. Re: [oslc-core] Resource Preview and Deletated Dialogs documents are now ready for review

Thanks for the thorough review. comments below...

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data

From:        Martin P Pain/UK/IBM
To:        jamsden@us.ibm.com
Date:        11/12/2015 08:17 AM
Subject:        Links from LDPCs to dialogs in RDF, XML, compact resource, etc. Re: [oslc-core] Resource Preview and Deletated Dialogs documents are now ready for review

My feedback on dialogs document:
Example 6 has propeties on an LDPC that link to the Dialog descriptors. I haven't seen anywhere where that usage is defined. (I don't think it would be a bad thing to do, but we haven't described it yet it's in our example).

<jra>This is covered by 6.1.3 Clients MAY request that the dialog descriptors for an LDP container are returned inline using the Prefer request header [RFC7240] , and by 6.1.7 Servers MAY also provide delegated dialog discovery using the ServiceProvider and Service resource and the oslc:creationDialog and oslc:selectionDialog properties. if the LDPC is also a Service. It is also consistent with LDP 1.0 option of including Link properties in the Link header and as properties of the resource in the request response body.</jra>
Example 8 is in XML when previous examples are in Turtle. Is the variation intentional? I'd think it would be more likely to be confusing. Is it because this is the OSLC v2 version, which required RDF/XML as the base representation, where the previous examples were for use with LDP which requires Turtle as a minimum (IIRC)?

<jra>I left it in RDF/XML because 1) the example comes from the OSLC 2.0 specification and 2) to provide examples that demonstrated different options/capabilities.</jra>
Just before example 11 we mention the compact resource. I expect this was copied from the preview document. It sounds out of place here.

<jra>That's actually correct. The JSON includes an oslc:label so the delegated dialog can be displayed without having to use resource preview to get something to display. I'll clarify.</jra>
Example 13 could handle resize events as well.

<jra>That would probably be better done in a different event listener for better functional cohesion. This example if "Listen for Dialog Results". Do we need to add another example?</jra>
Implementation conformance:
6.1.2 says "to successful HTTP requests", but 6.1.1 just says "to HTTP requests".

<jra>Fixed (added successful to 6.1.1)</jra>
6.1.7: Should this be something like "If using ServiceProvider discovery [or whatever else we use to refer to v2 discovery elsewhere] then servers MUST [use oslc:creationDialog and oslc:selectionDialog]".

<jra>No, that's a hidden MAY - if using ... MUST ... which might be confusing. And what is returned by ServiceProvider is specified in the ResourceShape.</jra>
Resource constraints:
I;d expect the "summary" of the shape to include the term "dialog descriptor". Also, does the "name" have to match the fragment in the URI? If not, I'd suggest that should be "Dialog descriptor" too.

<jra>I fixed the summary to indicate its the Dialog vocabulary element that is being constrained. That summary way generic boilerplate.

The Name: field is derived from the ResourceShape - I agree that the vocabulary item should be DialogDescriptor, not Dialog since it has an oslc:dialog property which is a HTML dialog. That was always confusing. But its left from OSLC 2.0 and there's little motivation to rename it now.</jra>
We've probably mentioned this previously, but the meaning of multiple resource shapes or multiple resource types on a dialog descriptor is ambiguous: is it "all" or "any"?

<jra>That would be defined in Core Vocabulary specification where ResourceShape is defined (pulled in from OSLC 2.0 Appendix A). Regarding the specific question, it doesn't actually apply in OSLC Core 3.0 since only one constraint on Dialog is specified by core. A broader answer would have to include the context in which the constraints are being applied. I don't think that's actually addressed. Servers could pick and choose based on what they need, and might be free to use and or or since ResouceConstraints closed-world mechanisms applied to open-world data. </jra>
B. Dialog results JSON
The columns are in a different order to the resource shape tables. Perhaps in the resource shape tables "occurs" shouldn't be the second column.

<jra>These aren't resource shapes, they're JSON, following the name: type order typical of JSON-LD. This column ordering seems more fit for the purpose</jra>

----- Original message -----
From: "Jim Amsden" <jamsden@us.ibm.com>
Sent by: <oslc-core@lists.oasis-open.org>
To: "OASIS OSLC Core TC Discussion List (oslc-core@lists.oasis-open.org)" <oslc-core@lists.oasis-open.org>
Subject: [oslc-core] Resource Preview and Deletated Dialogs documents are now ready for review
Date: Tue, Nov 10, 2015 9:40 PMWe'

OSLC Core 3.0 Resource Preview is ready for TC review:

OSLC Core 3.0 Dialogs is ready for TC review:

Review comments can go to this mailing list. Any significant issues that require TC discussion and/or approval should be raised in OSLC Core issue tracker:

As a reminder, these reviews are in preparation for TC vote to submit OSLC Core 3.0 to public review. We had hoped to be at this point by the end of September, so we're likely to be a couple of months later than expected.

Attachments and Core Vocabulary are coming next, hopefully by the end of the week.

Jim Amsden, Senior Technical Staff Member

OSLC and Linked Lifecycle Data



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