Resource creation: keep it simple for integrations sake

Often the case when working with tool providers in exposing their capabilities via OSLC, the discussion always ends up on how to deal with all the complexities of that system.  There are rules for what is a valid change request properties needed for submissions like: required headline, required found in component (which in turn may require additional fields), etc, etc, etc.   My advice is for exposing these constraints and rules, especially from an integration interface protocol like OSLC, is to shield these complexities.  I am not advocating that these tool provider relax these submission rules or come up with a new way to create change requests from integration APIs (well maybe I am in a way).   In OSLC, there is a concept of creation factories which provide consumers with a URI in which to POST some content to create a new resource.  These factories could be based on a concept such as a creation template or a reference change request.  A creation template would be basically a blueprint or sample of what to pre-fill all the properties in a change request if the POST request has some missing pieces.  A reference change request would be an existing change request in the change management tool that is duplicated (aka copied) into a new change request and properties from the POST will override the copied fields.   Most common CM tools have both these capabilities but have not seen too many of them leverage these for a more simplified creation factory to make the job a little easier for integrating clients to not have to learn more about the CM tools submission constraints.  Be interested to hear if anyone has explored these options and their findings.

To add to this, when service providers advertise their support for creation factories they can associate additional meaning to them and there can be multiple creation factories per configuration context (service provider resource).  For example, a service provider could indicate which factory is the default one to use, define the rdf:type of resource created from the factory, link to an associated shape definition and other informative pieces such as the intended usage (defects, comments, etc).