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

["Jim Amsden" <jamsden@us.ibm.com>]

Martin,
Thanks for the thorough review. comments
below...


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575


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>
Cc:
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: http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/trunk/specs/resource-preview.html

OSLC Core 3.0 Dialogs is ready for TC review: http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/trunk/specs/dialogs.html

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: https://issues.oasis-open.org/browse/oslccore.

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
919-525-6575