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-13) dialogs-v3.html final editing issues


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

James Amsden updated OSLCCORE-13:
---------------------------------

    Proposal: 
If OSLC Core 3.0 defines a property oslc:resourceShape, (or any other property such as oslc:constrainedBy), then OSLC should define the property values and meaning in a specific, normative way. Although OSLC 2.0 ResourceShapes are not defined by OSLC Core 3.0, they can be directly referenced in the 3.0 specification in a normative way subject to TC approval. So OSLC can be flexible in how resources dialogs are prefilled or resources are constrained.

W3C ldp:constrainedBy  specifies:

"4.2.1.6 LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a 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 [RFC5988], to all responses to requests that fail due to violation of those constraints. For example, a server that refuses resource creation requests via HTTP PUT, POST, or PATCH would return this Link header on its 4xx responses to such requests. The same Link header MAY be provided on other responses. LDP neither defines nor constrains the representation of the link's target resource. Natural language constraint documents are therefore permitted, although machine-readable ones facilitate better client interactions. The appropriate context URI can vary based on the request's semantics and method; unless the response is otherwise constrained, the default (the effective request URI) SHOULD be used."

This language should be sufficient for OSLC and would allow the use of no constraints, existing OSLC 2.0 ResourceShapes, or whatever constraint/shape language W3C eventually adopts.

Property olsc:resourceShape in Dialog, could be related to ldp:constrainedBy. That is, if a client posted contents in the dialog that did not match the shape, then the server would be expected to respond with a 4xx status code an include a Link header with ldp:constrainedBy to indicate the resource shape that was violated.




  was:
If OSLC Core 3.0 defines a property oslc:resourceShape, (or any other property such as oslc:constrainedBy), then OSLC would need to define the property values and meaning in a specific, normative way. Since OSLC 2.0 ResourceShapes are not defined by OSLC Core 3.0, they cannot be directly references in the 3.0 specification in a normative way. So OSLC needs to be more flexible in how resources dialogs are prefilled or resources are constrained.

W3C ldp:constrainedBy already provides appropriate language:

"4.2.1.6 LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a 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 [RFC5988], to all responses to requests that fail due to violation of those constraints. For example, a server that refuses resource creation requests via HTTP PUT, POST, or PATCH would return this Link header on its 4xx responses to such requests. The same Link header MAY be provided on other responses. LDP neither defines nor constrains the representation of the link's target resource. Natural language constraint documents are therefore permitted, although machine-readable ones facilitate better client interactions. The appropriate context URI can vary based on the request's semantics and method; unless the response is otherwise constrained, the default (the effective request URI) SHOULD be used."

This language should be sufficient for OSLC and would allow the use of no constraints, existing OSLC 2.0 ResourceShapes, or whatever constraint/shape language W3C eventually adopts.

The proposal is that we replace olsc:resourceShape in Dialog, with ldp:constrainedBy. This reuses LDP while at the same time providing the same flexibility intended by oslc:resourceShape (which is not currently specified).




> dialogs-v3.html final editing issues
> ------------------------------------
>
>                 Key: OSLCCORE-13
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-13
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: James Amsden
>            Assignee: James Amsden
>
> 1. Section 5.3 Prefill, should oslc:resourceShape be ldp:constrainedBy to provide flexibility for how the dialog contents would be constrained? This would decouple dialogs from OSLC 2.0 Resource Shapes.
> Dialog property oslc:resourceShape is not sufficiently defined. It specifies the constraints for the dialog, but does not say how these constraints are specified in a standard way.



--
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]