Hi, Thank you Christanto for your suggestions - I'll take Stefan's questions as a basis to clarify my ideas around this.
I think we can and should find a common ground between Christanto's (pretty concrete) proposal and the (more vague) ideas that I drafted at [0]. That common ground might be a Java API used to access the underlying models, exposing their semantics in a way that clearly defines how they are used in Sling and possibly other applications. The format of the underlying models is not important, it's what they supply to us that's important. On Tue, Jan 8, 2019 at 11:44 AM Stefan Seifert <[email protected]> wrote: > 1. why defining a new "DSL" to describe the model metadata?... I would stick to defining a Java API to read the models, taking JSON Schema concepts as base semantics. > 2. do you plan to support only a single resource/node and it's properties. > what's with sub tree structures... I think taking a Hypermedia view on this and using links to define parent/child relations should help. Or maybe define higher-level "forms" or "documents" which combine lower-level items and are what an HTTP API would expose. > 3. one of the reasons why sling is why it is (without an explicit modeling > capability) is the rule #1 of david's > model "Data First, Structure Later. Maybe." [1]... I think this makes sense for prototyping but when creating a large system we're clearly in the "later" phase ;-) Having underlying Types would allow us to make the Sling HTTP API self-explaining (Hypermedia-driven) and remove "API ambiguities" that are too easy to create with Sling currently, IMHO. That might be an optional mode for Sling though, probably an alternate set of default servlets. > 4. the name "Models" can be mixed up with "Sling Models" [2]... I agree that we cannot hijack that name at this point, hence my proposal to define a "Sling Type System" which contains "Sling Types" instead of Models. > 5. you describe it should be possible to derive data models from JCR CND > definitions. do you think this should be the major use case?... If the focus is on a Java API to access Sling Type data, the type definitions can be generated from any suitable source. I think we should avoid JCR dependencies as much as possible but having a bridge to that can be useful. > 6. you describe some "other models" like FormModel, ActionsModel which sound > like hypermedia support.... I will need to prove that but I think all these can be defined using the Hypermedia Links concept. The Action of starting a Workflow for example can be modeled as a link with a workflow:start relation. Christanto, from some offline conversations that we had around this I think your focus is more on the UI side, whereas I'm more interested in the HTTP API / REST side of things. Hopefully we can define a common modeling^H^H^H^H^H^H^H^H Typing system which addresses both - I think finding this minimal common denominator should help us move this forward. -Bertrand [0] https://cwiki.apache.org/confluence/display/SLING/Sling+Type+System%3A+motivation+and+requirements > [1] https://wiki.apache.org/jackrabbit/DavidsModel > [2] https://sling.apache.org/documentation/bundles/models.html
