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: [OASIS Issue Tracker] (OSLCCORE-145) Resource shape for use with oslc.query and oslc.select


     [ https://issues.oasis-open.org/browse/OSLCCORE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Honey updated OSLCCORE-145:
---------------------------------

    Description: 
Currently, the only resource shape available for a query user is the maximum of one specified by oslc:resourceShape in the oslc:queryCapability. That resource shape relates to the properties of the query base URI and provides the properties that may be referenced in any oslc.properties query parameter value. It does not describe the properties of members. This does not seem very useful.

How does a client discover what member properties may be used with oslc.select or with oslc.where?

A service might not define any creation factory for that type of resource. Even if it does, not all the properties that can be specified at creation might be queryable. Some properties might not be supported at creation but be available as readonly.

This seems like a major omission from the OSLC Core 2.0 and 3.0.
We need a means for a client to discover which member properties:
1) Can be queried and specified in oslc.where
2) Can be returned in the result and specified in oslc.select


  was:
Currently, the only resource shape available for a query user is the maximum of one specified by oslc:resourceShape in the oslc:queryCapability. That resource shape relates to the properties of the query base URI and provides the properties that may be referenced in any oslc.properties query parameter value. It does not describe the properties of members.

How does a client discover what properties may be used with oslc.select or with oslc.where?

Not all member properties might be queryable. A resource shape for use with oslc.select might describe more OSLC properties than a resource shape for properties specified in oslc.where.

This seems like a major omission from the OSLC Core 2.0 and 3.0.



> Resource shape for use with oslc.query and oslc.select
> ------------------------------------------------------
>
>                 Key: OSLCCORE-145
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-145
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>          Components: Query
>            Reporter: David Honey
>            Assignee: James Amsden
>
> Currently, the only resource shape available for a query user is the maximum of one specified by oslc:resourceShape in the oslc:queryCapability. That resource shape relates to the properties of the query base URI and provides the properties that may be referenced in any oslc.properties query parameter value. It does not describe the properties of members. This does not seem very useful.
> How does a client discover what member properties may be used with oslc.select or with oslc.where?
> A service might not define any creation factory for that type of resource. Even if it does, not all the properties that can be specified at creation might be queryable. Some properties might not be supported at creation but be available as readonly.
> This seems like a major omission from the OSLC Core 2.0 and 3.0.
> We need a means for a client to discover which member properties:
> 1) Can be queried and specified in oslc.where
> 2) Can be returned in the result and specified in oslc.select



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


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