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: Questions on OSLC Discovery 3.0 (review fragment)


I'm reviewing https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/specs/discovery.html as at svn 332 but have pretty much got stuck trying to understand the relation between 2.0-style discovery resources and how things work in 3.0 with LDPCs.  I take the intention is for 2.0 resources being LDPCs but I don't see how this can work.  I thought I'd post here to try to clear up my ignorance - apologies for the noise.

I think I understand the creation factory material, and have some comments on that.

Section 5 (and Appendices 2-4)

I'm not understanding how to express a 2.0 style discovery into LDP style.  Forgive my ignorance here.

"The members of a ServiceProviderCatalog resource include ServiceProviderCatalogs and ServiceProvider LDPCs. ServiceProvider resource members include Service LDPCs. "

Is this use of "member" the same as used in the LDPC spec?  How can a LDPC contain resources of two different classes (ServiceProviderCatalogs and ServiceProviders) without using two different LDPCs.  An LDPC can only have one member relation, but my understanding is that

Section 5.1
I don't see how OPTIONS * on a server would return information about a ServiceProviderCatalogue, at least not in a standard way.  Is there a need to include this?

Creation factories

Section 5.4 describes how an LDPC advertises "the rdf:type of resources that can be created in the LDPC".  The cardinality of this Link rel needs to be zero-or-many, to match that of oslc:resourceType in Service documents.  Suggest making this clear. Also, that this is not a constraint on the rdf:types of resources in the LDPC - it is only a constraint on what resources can be _created_ in that LDPC.

Section 5.5 describes another means to impose constraints, of which ResourceShape from 2.0 is an example.  (Understood that other constrains schemes could also be used.)

There is a need to spell out what multiple such constrainedBy Link rels would mean.  The natural interpretation (to me) is that _all_ the constraints would need to be satisfied - a conjunction of all constraints.  However, this would not sit well with 2.0 useage of ResourceShape.  In 2.0, creation factories that list more than one ResourceShape mean disjunction.  I base this only on the wording in the Core 2.0 spec - "A Creation Factory MAY provide Resource Shapes that describe shapes of resources that may be created. ".It doesn't make practical sense to have multiple ResourceShapes, each of which, conjunctively, describe the shape of things that can be created.

The LDPC wording in section might suggest that at most one constrainedBy rel can be supplied - any thoughts on that?  If this were true, the "conjuctive/disjunctive" issue would be moot, but there would be another issue - how to express what in 2.0 is multiple ResourceShapes.  If multiple constrainedBys are permitted, can we ascribe the disjunctive interpretation?

There is also to my eye redundancy here between constrainedBy and resourceType.  Do we want to propagate that in 3.0? I'd like to see a rationalization, if possible, so that LDPC uses constrainedBy for both oslc:resourceType and oslc:resourceShape.

I think the wording pertaining to "Update" in this section should make clear that creation constraints and update constraints are logically distinct (they may be different) - it is not the case that the LDPC constraint on POST MUST apply to LDPR PUT.  Example 3 conflates these ideas "...POST or PUT..." which might not make for a good example.

Appendix A.3
Typo: Description: "An LDPC whose .... spurious quotation mark.

best wishes,

ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
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]