+1 for the idea. To restate. Given a resource, you should be able to define what properties that resource can contain and what child resources it can be the parent of.
Feedback: 1. There's some things that are implicit. For example, stating that a resource can be a parent of a resource would imply that you could perform the action to create the child resource. 2. Terminology We're still a REST platform, do we need to have actions that are different then the standard REST methods? Would we have something different? Looking at the code, I get confused between a type for a resource and a sling:resourceType. I believe these are different things. The resourceType defines how the data is rendered and the resourceType can be overridden. Where as the type of a resource as we are talking about defines it structure, without regard to how it's rendered. I hope these are different things :) - Jason On Tue, Oct 2, 2018, at 7:59 AM, Bertrand Delacretaz wrote: > Hi, > > Recent discussions with a number of people from the Sling community > [1] have helped clarify my thoughts about this, I have started a wiki > page at > https://cwiki.apache.org/confluence/display/SLING/Sling+Type+System%3A+motivation+and+requirements > and feedback is welcome, on that page or here. > > Roughly, the goal is to create a Sling Type System that defines much > more precisely what the various Resource Types can contain, how they > work together, etc. with the goal of generating self-describing > interfaces. > > Let's see where this leads, it's just rough ideas so far but it feels > like a useful unifying concept for Sling. > > -Bertrand > > [1] along with reading "a conversation with Alan Kay, creator of > Smalltalk" - https://queue.acm.org/detail.cfm?id=1039523
