dialogs-v3.html final editing issues

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.