Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hi, > Christanto's types know about "multiple" and "required" attributes Those are for AttributeDefinition. I don't think we need complex validation for Attribute. But for Property, pluggable validation is already supported by its API [1]. Cheers, Christanto [1] https://github.com/christanto/sling-whiteboard/blob/a2cf3643b0c94181200705b7a11c756dc8684bd3/modeling/org.apache.sling.types.api/src/main/java/org/apache/sling/types/data/Property.java#L92 On Thu, Jan 10, 2019 at 10:45 PM Bertrand Delacretaz wrote: > On Thu, Jan 10, 2019 at 3:36 PM Carsten Ziegeler > wrote: > > This seems to have a lot in common what we already tried with the > > validator api/module. > > > > https://github.com/apache/sling-org-apache-sling-validation-api ... > > Indeed, thanks for pointing this out. > > I was planning to merge ideas once we progress - for now I think > Christanto's types know about "multiple" and "required" attributes, we > probably need to add a more opaque Validator interface that might use > this existing module underneath. > > But that can happen once we have at least an embryo of the Types API > which I think should start as small as possible. > > -Bertrand >
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hi, I extract out the module into API bundle and implementation bundle. I also provide an example based on SlingShot content to generate HAL response. See the details at https://github.com/christanto/sling-whiteboard/tree/master/modeling Cheers, Christanto On Thu, Jan 10, 2019 at 8:59 PM Bertrand Delacretaz wrote: > On Thu, Jan 10, 2019 at 4:33 AM Christanto Leonardo > wrote: > > ...BTW I rename things to use "type" instead of "model"... > > Great! > > Would it be ok for you to extract the key interfaces into a separate > module? > > I'm thinking of Types, DataType, AttributeDefinition and maybe a few > others - just a minimal core that can be used to use the types, > without considering how they are actually defined and with ideally no > implementation details. > > My angle is to try to reduce the amount of things on which we need to > agree on at this point - I'd then be able to recreate my minimal > resource-schemas example based on these APIs, to verify that they > provide what I need there, and you could pursue explorations > independently on your side. > > -Bertrand >
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
On Thu, Jan 10, 2019 at 3:36 PM Carsten Ziegeler wrote: > This seems to have a lot in common what we already tried with the > validator api/module. > > https://github.com/apache/sling-org-apache-sling-validation-api ... Indeed, thanks for pointing this out. I was planning to merge ideas once we progress - for now I think Christanto's types know about "multiple" and "required" attributes, we probably need to add a more opaque Validator interface that might use this existing module underneath. But that can happen once we have at least an embryo of the Types API which I think should start as small as possible. -Bertrand
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
This seems to have a lot in common what we already tried with the validator api/module. https://github.com/apache/sling-org-apache-sling-validation-api Carsten Bertrand Delacretaz wrote On Thu, Jan 10, 2019 at 4:33 AM Christanto Leonardo wrote: ...BTW I rename things to use "type" instead of "model"... Great! Would it be ok for you to extract the key interfaces into a separate module? I'm thinking of Types, DataType, AttributeDefinition and maybe a few others - just a minimal core that can be used to use the types, without considering how they are actually defined and with ideally no implementation details. My angle is to try to reduce the amount of things on which we need to agree on at this point - I'd then be able to recreate my minimal resource-schemas example based on these APIs, to verify that they provide what I need there, and you could pursue explorations independently on your side. -Bertrand -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
On Thu, Jan 10, 2019 at 4:33 AM Christanto Leonardo wrote: > ...BTW I rename things to use "type" instead of "model"... Great! Would it be ok for you to extract the key interfaces into a separate module? I'm thinking of Types, DataType, AttributeDefinition and maybe a few others - just a minimal core that can be used to use the types, without considering how they are actually defined and with ideally no implementation details. My angle is to try to reduce the amount of things on which we need to agree on at this point - I'd then be able to recreate my minimal resource-schemas example based on these APIs, to verify that they provide what I need there, and you could pursue explorations independently on your side. -Bertrand
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
BTW I rename things to use "type" instead of "model". See for example https://github.com/christanto/sling-whiteboard/blob/c8d06a5520bd89ecf97243088e37f75bacf96d38/modeling/src/main/java/org/apache/sling/types/TypeSystem.java Cheers, Christanto
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hi, On Wed, Jan 9, 2019 at 9:57 AM Jason E Bailey wrote: > > On Tue, Jan 8, 2019, at 7:43 PM, Christanto Leonardo wrote: > > > > ``` > > + /mycontent2 > > - jcr:primaryNodeType = "nt:unstructured" > > - sling:resourceType = "my/page" > > - my:created = "2019-01-01T00:00:00Z" > > - my:title = "Title 1" > > ``` > > > > Here, you simply define a DataModel for `/apps/my/page` having my:created > > and my:title properties. > > So when other code inspect the resource (/mycontent2) using DataModel, it > > will get Property instances for my:created and my:title. > > > > Okay, I think I'm getting there, it's just that we have a difference in > terminology. Your idea is along the lines of being able to define a set of > values that is exposed for a given resource. > > When I talk of a Type, it's not just a definition of what is there, it's > the enforcement of those values. So in defining a "sling:type" of "folder" > I expect to be able to define what values must be provided in order to > create a resource of that type and that is respected without regard to the > ResourceProvider that is responsible for that location. > Yes it can be done. We just need to define the model itself to support it. So far my example is about reading, the Property.class itself can be used during writing. Cheers, Christanto
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hi, On Tue, Jan 8, 2019 at 9:54 PM Bertrand Delacretaz wrote: > Hi, > > On Tue, Jan 8, 2019 at 2:15 PM Bertrand Delacretaz > wrote: > > ...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 > > I have had a closer look at > https://github.com/christanto/sling-whiteboard/tree/master/modeling > and I think the above is contained in that, but I think we might > reduce that "common ground" to a smaller core API to start with. > The core is basically just [Models.class]( https://github.com/christanto/sling-whiteboard/blob/08fd3637c4045470e2b2ba8f8d9bbf4fcf82c211/modeling/src/main/java/org/apache/sling/modeling/Models.java ) BTW, I think Sling should really consider enhancing the Adaptable interface for this instead as I explained at https://github.com/christanto/sling-whiteboard/blob/master/modeling/docs/explainer.md#alternative-way-getting-the-models This way we can inspect any adaptable on what adaptations are available. > > I'm using the "Content Types" name for now to avoid both the Models > and Sling terms. > > How about this, roughly? > > -A ContentType can be retrieved by name from the TypeSystem service > -A ContentType contains a list of Properties (name, data type, > validation etc..) and nested ContentTypes > -A ContentType can include a list of Links > -A Link has a Relation, Description and Target > -Link Relations are namespaced and the TypeSystem can reserve some > namespace prefixes > > I think this would be enough for my use case of implementing a > self-describing HTTP API - there's probably a number of details > missing but that would be the essence of the Type System API. > > Christanto, would that work for you assuming we move the above into a > "type system core" module to allow us to work in parallel on the > "details" in other modules? > Certainly Sling can decide to have `org.apache.sling.types.rest.ContentType` interface, such that one can do something like this: ``` Resource content = slingRequest.getResource(); ContentType contentType = content.adaptTo(ContentType.class); // Use the contentType contentType.getProperties(); contentType.getLinks(); ``` Other modules can decide to define their own modules for their own purposes. Cheers, Christanto > > -Bertrand >
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
On Tue, Jan 8, 2019, at 7:43 PM, Christanto Leonardo wrote: > > ``` > + /mycontent2 > - jcr:primaryNodeType = "nt:unstructured" > - sling:resourceType = "my/page" > - my:created = "2019-01-01T00:00:00Z" > - my:title = "Title 1" > ``` > > Here, you simply define a DataModel for `/apps/my/page` having my:created > and my:title properties. > So when other code inspect the resource (/mycontent2) using DataModel, it > will get Property instances for my:created and my:title. > Okay, I think I'm getting there, it's just that we have a difference in terminology. Your idea is along the lines of being able to define a set of values that is exposed for a given resource. When I talk of a Type, it's not just a definition of what is there, it's the enforcement of those values. So in defining a "sling:type" of "folder" I expect to be able to define what values must be provided in order to create a resource of that type and that is respected without regard to the ResourceProvider that is responsible for that location.
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
cribe it should be possible to derive data models from JCR > CND > > > definitions. do you think this should be the major use case? JCR CND > > > definitions are quite out-of-fashion nowadays, and used more for > historical > > > reasons (or for performance optimizations because oak indexes are > based on > > > them). the tooling around them is not good (e.g. difficult to > > > update/replace them in a running system). > > > > > > 6. you describe some "other models" like FormModel, ActionsModel which > > > sound like hypermedia support. i do not fully understand how hypermedia > > > support fits into the other parts you describe which primarily > describe the > > > data model and not the actions for them. where does this hypermedia > > > metadata come from? > > > > > > stefan > > > > > > [1] https://wiki.apache.org/jackrabbit/DavidsModel > > > [2] https://sling.apache.org/documentation/bundles/models.html > > > > > > > > > > > > >-Original Message- > > > >From: Christanto Leonardo [mailto:christanto.leona...@gmail.com] > > > >Sent: Tuesday, January 8, 2019 4:03 AM > > > >To: dev@sling.apache.org > > > >Subject: Re: Sling Type System: started a wiki page for concepts, > ideas, > > > >motivation > > > > > > > >Hello, > > > > > > > >I am currently working on the proposal to introduce the concept of > > > modeling > > > >in Sling. See it at < > > > >https://github.com/christanto/sling-whiteboard/tree/master/modeling>. > > > >One is especially encouraged to read the explainer at < > > > >https://github.com/christanto/sling- > > > >whiteboard/blob/master/modeling/docs/explainer.md > > > >>. > > > > > > > >My hope is that the Sling Modeling Framework can provide the ability > to > > > >model many concepts in the application, starting with the typing > system of > > > >the resource (i.e. the resource type definition) as the lowest layer. > > > > > > > >Please let me know what you think. I plan to continue developing this > > > >proposal. > > > > > > > >Cheers, > > > >Christanto > > > > > > > >On 2018/10/02 11:59:08, 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+moti > > > >vation+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> > > > >> > > > > > >
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
[1]. this was stated a very long time ago. would be nice if > you can > > > add a reference to your explainer page to it as well and explain why > you > > > think different nowadays (i think there are good reasons for it, but it > > > always depends on the use cases). > > > > > > 4. the name "Models" can be mixed up with "Sling Models" [2] which > points > > > somewhat into the same direction but is currently based on different > > > concepts and is already used much. but i suppose this can be sorted out > > > later to decide if this new approach can be "Sling Models 2.0" or the > new > > > things should get a different name (like Type System). still it would > make > > > sense to also add a reference to sling models to the explainer. > > > > > > 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? JCR CND > > > definitions are quite out-of-fashion nowadays, and used more for > historical > > > reasons (or for performance optimizations because oak indexes are > based on > > > them). the tooling around them is not good (e.g. difficult to > > > update/replace them in a running system). > > > > > > 6. you describe some "other models" like FormModel, ActionsModel which > > > sound like hypermedia support. i do not fully understand how hypermedia > > > support fits into the other parts you describe which primarily > describe the > > > data model and not the actions for them. where does this hypermedia > > > metadata come from? > > > > > > stefan > > > > > > [1] https://wiki.apache.org/jackrabbit/DavidsModel > > > [2] https://sling.apache.org/documentation/bundles/models.html > > > > > > > > > > > > >-Original Message- > > > >From: Christanto Leonardo [mailto:christanto.leona...@gmail.com] > > > >Sent: Tuesday, January 8, 2019 4:03 AM > > > >To: dev@sling.apache.org > > > >Subject: Re: Sling Type System: started a wiki page for concepts, > ideas, > > > >motivation > > > > > > > >Hello, > > > > > > > >I am currently working on the proposal to introduce the concept of > > > modeling > > > >in Sling. See it at < > > > >https://github.com/christanto/sling-whiteboard/tree/master/modeling>. > > > >One is especially encouraged to read the explainer at < > > > >https://github.com/christanto/sling- > > > >whiteboard/blob/master/modeling/docs/explainer.md > > > >>. > > > > > > > >My hope is that the Sling Modeling Framework can provide the ability > to > > > >model many concepts in the application, starting with the typing > system of > > > >the resource (i.e. the resource type definition) as the lowest layer. > > > > > > > >Please let me know what you think. I plan to continue developing this > > > >proposal. > > > > > > > >Cheers, > > > >Christanto > > > > > > > >On 2018/10/02 11:59:08, 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+moti > > > >vation+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> > > > >> > > > > > >
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
I really appreciate the thought that you put into this. If you are utilizing the JCR Resource Provider to store a resource you have to declare a jcr:primaryType, and you are then bound by the definition of the node as to what you can add as an attribute or a child type. So there is such thing as "creating a resource without a JCR node type" if that resource is to be persisted in the JCR. One of the core tenants of Sling is that everything is a Resource. One of my expectations of a Type system is that I can create a type by POST and retrieve the structure of the type via a GET. That the definitions of a Type are themselves resources. I may be missing this from your whitepaper, is that doable? -- Jason On Tue, Jan 8, 2019, at 9:11 AM, Christanto Leonardo wrote: > Hi, > > > 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? JCR CND > definitions are quite out-of-fashion nowadays, and used more for historical > reasons (or for performance optimizations because oak indexes are based on > them). the tooling around them is not good (e.g. difficult to > update/replace them in a running system). > > The purpose of the Sling Modeling Framework is to model your applications, > possibly the existing ones. > So if you have an existing resource defined in JCR with all the node types > (e.g. cq:PageContent resource), the modeling framework must be able to > model that. > If you create a new resource without JCR node type, then when defining that > resource type you don't need to use CND. > > I think it is already explained at: > >1. > > https://github.com/christanto/sling-whiteboard/blob/master/modeling/docs/explainer.md#data-modeling-using-jcr-node-types >2. > > https://github.com/christanto/sling-whiteboard/blob/master/modeling/docs/explainer.md#modeling-the-underlying-platforms-typing-system > > Cheers, > Christanto > > > On Tue, Jan 8, 2019 at 6:44 PM Stefan Seifert > wrote: > > > hello christanto. > > > > thanks for bringing this up! some first questions after a first read: > > > > 1. why defining a new "DSL" to describe the model metadata? what's with > > existing things like json schema. defining a completely new DSL often has > > the risk of not getting it "right" in the first place. > > > > 2. do you plan to support only a single resource/node and it's properties. > > what's with sub tree structures, that are supported by JCR CND definitions? > > more complex data models like forms are unlikely to be represented by a > > single resource. or maybe that is already covered with the property > > handlers although the name does not indicate it. > > > > 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]. this was stated a very long time ago. would be nice if you can > > add a reference to your explainer page to it as well and explain why you > > think different nowadays (i think there are good reasons for it, but it > > always depends on the use cases). > > > > 4. the name "Models" can be mixed up with "Sling Models" [2] which points > > somewhat into the same direction but is currently based on different > > concepts and is already used much. but i suppose this can be sorted out > > later to decide if this new approach can be "Sling Models 2.0" or the new > > things should get a different name (like Type System). still it would make > > sense to also add a reference to sling models to the explainer. > > > > 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? JCR CND > > definitions are quite out-of-fashion nowadays, and used more for historical > > reasons (or for performance optimizations because oak indexes are based on > > them). the tooling around them is not good (e.g. difficult to > > update/replace them in a running system). > > > > 6. you describe some "other models" like FormModel, ActionsModel which > > sound like hypermedia support. i do not fully understand how hypermedia > > support fits into the other parts you describe which primarily describe the > > data model and not the actions for them. where does this hypermedia > > metadata come from? > > > > stefan > > > > [1] https://wiki.apache.org/jackrabbit/DavidsModel > > [2] https://sling.apache.org/documentation/bundles/models.html > > > > > > > > >-
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hi, > 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? JCR CND definitions are quite out-of-fashion nowadays, and used more for historical reasons (or for performance optimizations because oak indexes are based on them). the tooling around them is not good (e.g. difficult to update/replace them in a running system). The purpose of the Sling Modeling Framework is to model your applications, possibly the existing ones. So if you have an existing resource defined in JCR with all the node types (e.g. cq:PageContent resource), the modeling framework must be able to model that. If you create a new resource without JCR node type, then when defining that resource type you don't need to use CND. I think it is already explained at: 1. https://github.com/christanto/sling-whiteboard/blob/master/modeling/docs/explainer.md#data-modeling-using-jcr-node-types 2. https://github.com/christanto/sling-whiteboard/blob/master/modeling/docs/explainer.md#modeling-the-underlying-platforms-typing-system Cheers, Christanto On Tue, Jan 8, 2019 at 6:44 PM Stefan Seifert wrote: > hello christanto. > > thanks for bringing this up! some first questions after a first read: > > 1. why defining a new "DSL" to describe the model metadata? what's with > existing things like json schema. defining a completely new DSL often has > the risk of not getting it "right" in the first place. > > 2. do you plan to support only a single resource/node and it's properties. > what's with sub tree structures, that are supported by JCR CND definitions? > more complex data models like forms are unlikely to be represented by a > single resource. or maybe that is already covered with the property > handlers although the name does not indicate it. > > 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]. this was stated a very long time ago. would be nice if you can > add a reference to your explainer page to it as well and explain why you > think different nowadays (i think there are good reasons for it, but it > always depends on the use cases). > > 4. the name "Models" can be mixed up with "Sling Models" [2] which points > somewhat into the same direction but is currently based on different > concepts and is already used much. but i suppose this can be sorted out > later to decide if this new approach can be "Sling Models 2.0" or the new > things should get a different name (like Type System). still it would make > sense to also add a reference to sling models to the explainer. > > 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? JCR CND > definitions are quite out-of-fashion nowadays, and used more for historical > reasons (or for performance optimizations because oak indexes are based on > them). the tooling around them is not good (e.g. difficult to > update/replace them in a running system). > > 6. you describe some "other models" like FormModel, ActionsModel which > sound like hypermedia support. i do not fully understand how hypermedia > support fits into the other parts you describe which primarily describe the > data model and not the actions for them. where does this hypermedia > metadata come from? > > stefan > > [1] https://wiki.apache.org/jackrabbit/DavidsModel > [2] https://sling.apache.org/documentation/bundles/models.html > > > > >-Original Message- > >From: Christanto Leonardo [mailto:christanto.leona...@gmail.com] > >Sent: Tuesday, January 8, 2019 4:03 AM > >To: dev@sling.apache.org > >Subject: Re: Sling Type System: started a wiki page for concepts, ideas, > >motivation > > > >Hello, > > > >I am currently working on the proposal to introduce the concept of > modeling > >in Sling. See it at < > >https://github.com/christanto/sling-whiteboard/tree/master/modeling>. > >One is especially encouraged to read the explainer at < > >https://github.com/christanto/sling- > >whiteboard/blob/master/modeling/docs/explainer.md > >>. > > > >My hope is that the Sling Modeling Framework can provide the ability to > >model many concepts in the application, starting with the typing system of > >the resource (i.e. the resource type definition) as the lowest layer. > > > >Please let me know what you think. I plan to continue developing this > >proposal. > > > >Cheers, > >Christanto > > > >On 2018/10/02 11:59:08, Bertrand Delacretaz wrote: > >> Hi,&
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hi, On Tue, Jan 8, 2019 at 2:15 PM Bertrand Delacretaz wrote: > ...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 I have had a closer look at https://github.com/christanto/sling-whiteboard/tree/master/modeling and I think the above is contained in that, but I think we might reduce that "common ground" to a smaller core API to start with. I'm using the "Content Types" name for now to avoid both the Models and Sling terms. How about this, roughly? -A ContentType can be retrieved by name from the TypeSystem service -A ContentType contains a list of Properties (name, data type, validation etc..) and nested ContentTypes -A ContentType can include a list of Links -A Link has a Relation, Description and Target -Link Relations are namespaced and the TypeSystem can reserve some namespace prefixes I think this would be enough for my use case of implementing a self-describing HTTP API - there's probably a number of details missing but that would be the essence of the Type System API. Christanto, would that work for you assuming we move the above into a "type system core" module to allow us to work in parallel on the "details" in other modules? -Bertrand
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hi, > 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]. this was stated a very long time ago. would be nice if you can add a reference to your explainer page to it as well and explain why you think different nowadays (i think there are good reasons for it, but it always depends on the use cases). David's Model clearly made a mistake about the idea of typing. Even if there is data, it is still have structure and type. Otherwise, how can I read the data? The argument brought by David's Model is really about strong typing vs weak typing, which I think simply a counter argument against RDBMS at that time, which adopts strong typing. What I am trying to address is the lack of reflection system in Sling. And the lack of it makes Sling betrays the idea of REST itself, which leverages the uniform interface as a core concept. Just imagine that in REST, you can have a generic client (e.g. Firefox) to handle HTML by simply following HTML spec, without knowing the application specific semantics. Cheers, Christanto On Tue, Jan 8, 2019 at 6:44 PM Stefan Seifert wrote: > hello christanto. > > thanks for bringing this up! some first questions after a first read: > > 1. why defining a new "DSL" to describe the model metadata? what's with > existing things like json schema. defining a completely new DSL often has > the risk of not getting it "right" in the first place. > > 2. do you plan to support only a single resource/node and it's properties. > what's with sub tree structures, that are supported by JCR CND definitions? > more complex data models like forms are unlikely to be represented by a > single resource. or maybe that is already covered with the property > handlers although the name does not indicate it. > > 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]. this was stated a very long time ago. would be nice if you can > add a reference to your explainer page to it as well and explain why you > think different nowadays (i think there are good reasons for it, but it > always depends on the use cases). > > 4. the name "Models" can be mixed up with "Sling Models" [2] which points > somewhat into the same direction but is currently based on different > concepts and is already used much. but i suppose this can be sorted out > later to decide if this new approach can be "Sling Models 2.0" or the new > things should get a different name (like Type System). still it would make > sense to also add a reference to sling models to the explainer. > > 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? JCR CND > definitions are quite out-of-fashion nowadays, and used more for historical > reasons (or for performance optimizations because oak indexes are based on > them). the tooling around them is not good (e.g. difficult to > update/replace them in a running system). > > 6. you describe some "other models" like FormModel, ActionsModel which > sound like hypermedia support. i do not fully understand how hypermedia > support fits into the other parts you describe which primarily describe the > data model and not the actions for them. where does this hypermedia > metadata come from? > > stefan > > [1] https://wiki.apache.org/jackrabbit/DavidsModel > [2] https://sling.apache.org/documentation/bundles/models.html > > > > >-Original Message- > >From: Christanto Leonardo [mailto:christanto.leona...@gmail.com] > >Sent: Tuesday, January 8, 2019 4:03 AM > >To: dev@sling.apache.org > >Subject: Re: Sling Type System: started a wiki page for concepts, ideas, > >motivation > > > >Hello, > > > >I am currently working on the proposal to introduce the concept of > modeling > >in Sling. See it at < > >https://github.com/christanto/sling-whiteboard/tree/master/modeling>. > >One is especially encouraged to read the explainer at < > >https://github.com/christanto/sling- > >whiteboard/blob/master/modeling/docs/explainer.md > >>. > > > >My hope is that the Sling Modeling Framework can provide the ability to > >model many concepts in the application, starting with the typing system of > >the resource (i.e. the resource type definition) as the lowest layer. > > > >Please let me know what you think. I plan to continue developing this > >proposal. > > > >Cheers, > >Christanto > > > >On 2018/10/02 11:59:08, Bertrand Delacre
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hello, > 2. do you plan to support only a single resource/node and it's properties. what's with sub tree structures, that are supported by JCR CND definitions? more complex data models like forms are unlikely to be represented by a single resource. or maybe that is already covered with the property handlers although the name does not indicate it. So far I just don't see a need to define the sub tree explicitly. In the end the PropertyHandler will handle the retrieval/persistent to the persistence later. See [TextPropertyImpl] for example. I think this is good because the underlying persistence can be changed by swapping the PropertyHandler implementations. Cheers, Christanto [TextPropertyImpl] https://github.com/christanto/sling-whiteboard/blob/08fd3637c4045470e2b2ba8f8d9bbf4fcf82c211/modeling/src/main/java/org/apache/sling/modeling/data/commons/impl/TextPropertyImpl.java#L51 On Tue, Jan 8, 2019 at 6:44 PM Stefan Seifert wrote: > hello christanto. > > thanks for bringing this up! some first questions after a first read: > > 1. why defining a new "DSL" to describe the model metadata? what's with > existing things like json schema. defining a completely new DSL often has > the risk of not getting it "right" in the first place. > > 2. do you plan to support only a single resource/node and it's properties. > what's with sub tree structures, that are supported by JCR CND definitions? > more complex data models like forms are unlikely to be represented by a > single resource. or maybe that is already covered with the property > handlers although the name does not indicate it. > > 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]. this was stated a very long time ago. would be nice if you can > add a reference to your explainer page to it as well and explain why you > think different nowadays (i think there are good reasons for it, but it > always depends on the use cases). > > 4. the name "Models" can be mixed up with "Sling Models" [2] which points > somewhat into the same direction but is currently based on different > concepts and is already used much. but i suppose this can be sorted out > later to decide if this new approach can be "Sling Models 2.0" or the new > things should get a different name (like Type System). still it would make > sense to also add a reference to sling models to the explainer. > > 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? JCR CND > definitions are quite out-of-fashion nowadays, and used more for historical > reasons (or for performance optimizations because oak indexes are based on > them). the tooling around them is not good (e.g. difficult to > update/replace them in a running system). > > 6. you describe some "other models" like FormModel, ActionsModel which > sound like hypermedia support. i do not fully understand how hypermedia > support fits into the other parts you describe which primarily describe the > data model and not the actions for them. where does this hypermedia > metadata come from? > > stefan > > [1] https://wiki.apache.org/jackrabbit/DavidsModel > [2] https://sling.apache.org/documentation/bundles/models.html > > > > >-Original Message- > >From: Christanto Leonardo [mailto:christanto.leona...@gmail.com] > >Sent: Tuesday, January 8, 2019 4:03 AM > >To: dev@sling.apache.org > >Subject: Re: Sling Type System: started a wiki page for concepts, ideas, > >motivation > > > >Hello, > > > >I am currently working on the proposal to introduce the concept of > modeling > >in Sling. See it at < > >https://github.com/christanto/sling-whiteboard/tree/master/modeling>. > >One is especially encouraged to read the explainer at < > >https://github.com/christanto/sling- > >whiteboard/blob/master/modeling/docs/explainer.md > >>. > > > >My hope is that the Sling Modeling Framework can provide the ability to > >model many concepts in the application, starting with the typing system of > >the resource (i.e. the resource type definition) as the lowest layer. > > > >Please let me know what you think. I plan to continue developing this > >proposal. > > > >Cheers, > >Christanto > > > >On 2018/10/02 11:59:08, 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 > >
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hello, > 1. why defining a new "DSL" to describe the model metadata? what's with existing things like json schema. defining a completely new DSL often has the risk of not getting it "right" in the first place. You still need the runtime API. In this case DataMode.class, Property.class and other models. Even if you define things using JSON Schema, you don't want to use JSON API (e.g. JSONObject.class) there. So the model API itself is just another Java interface leveraging OSGi. Take DataModel.class. One can define a data model definition by registering a [PropertyProvider] component, and implement it by reading the information from JSON. You can also imagine that implementing it using Java annotation makes sense as well. Cheers, Christanto [PropertyProvider] https://github.com/christanto/sling-whiteboard/blob/08fd3637c4045470e2b2ba8f8d9bbf4fcf82c211/modeling/src/main/java/org/apache/sling/modeling/data/spi/PropertyProvider.java On Tue, Jan 8, 2019 at 6:44 PM Stefan Seifert wrote: > hello christanto. > > thanks for bringing this up! some first questions after a first read: > > 1. why defining a new "DSL" to describe the model metadata? what's with > existing things like json schema. defining a completely new DSL often has > the risk of not getting it "right" in the first place. > > 2. do you plan to support only a single resource/node and it's properties. > what's with sub tree structures, that are supported by JCR CND definitions? > more complex data models like forms are unlikely to be represented by a > single resource. or maybe that is already covered with the property > handlers although the name does not indicate it. > > 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]. this was stated a very long time ago. would be nice if you can > add a reference to your explainer page to it as well and explain why you > think different nowadays (i think there are good reasons for it, but it > always depends on the use cases). > > 4. the name "Models" can be mixed up with "Sling Models" [2] which points > somewhat into the same direction but is currently based on different > concepts and is already used much. but i suppose this can be sorted out > later to decide if this new approach can be "Sling Models 2.0" or the new > things should get a different name (like Type System). still it would make > sense to also add a reference to sling models to the explainer. > > 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? JCR CND > definitions are quite out-of-fashion nowadays, and used more for historical > reasons (or for performance optimizations because oak indexes are based on > them). the tooling around them is not good (e.g. difficult to > update/replace them in a running system). > > 6. you describe some "other models" like FormModel, ActionsModel which > sound like hypermedia support. i do not fully understand how hypermedia > support fits into the other parts you describe which primarily describe the > data model and not the actions for them. where does this hypermedia > metadata come from? > > stefan > > [1] https://wiki.apache.org/jackrabbit/DavidsModel > [2] https://sling.apache.org/documentation/bundles/models.html > > > > >-Original Message- > >From: Christanto Leonardo [mailto:christanto.leona...@gmail.com] > >Sent: Tuesday, January 8, 2019 4:03 AM > >To: dev@sling.apache.org > >Subject: Re: Sling Type System: started a wiki page for concepts, ideas, > >motivation > > > >Hello, > > > >I am currently working on the proposal to introduce the concept of > modeling > >in Sling. See it at < > >https://github.com/christanto/sling-whiteboard/tree/master/modeling>. > >One is especially encouraged to read the explainer at < > >https://github.com/christanto/sling- > >whiteboard/blob/master/modeling/docs/explainer.md > >>. > > > >My hope is that the Sling Modeling Framework can provide the ability to > >model many concepts in the application, starting with the typing system of > >the resource (i.e. the resource type definition) as the lowest layer. > > > >Please let me know what you think. I plan to continue developing this > >proposal. > > > >Cheers, > >Christanto > > > >On 2018/10/02 11:59:08, Bertrand Delacretaz wrote: > >> Hi,> > >> > >> Recent discussions with a number of people from the Sling community> > >> [1] have helped clarify my th
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
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 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
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hello, > 6. you describe some "other models" like FormModel, ActionsModel which sound like hypermedia support. i do not fully understand how hypermedia support fits into the other parts you describe which primarily describe the data model and not the actions for them. where does this hypermedia metadata come from? I think example is best to explain this. I will provide it. In essence, a model can be anything. For example, I can define ActionsModel, which is a set of HTTP operations applicable for a given resource. Another one is FormModel, which is an edit form definition of a given resource. Since the form deals with data the end of the day, the FormModel may not need to repeat the data definition again (e.g. field1 is required), by simply leveraging/binding to the DataModel. (Example will make things clear later on.) Obviously, you may also think that creating a CreateFormModel makes sense as well. Then you can have a servlet using those models to expose hypermedia API. So instead of just dumping the resource data indiscriminately to the client like the Sling Default Servlet is doing, the models will drive what actions are available, what form structure/definition can be shown for the client to edit the resource, etc. And the models are not limited for REST API only. You can expose any API that you may need. e.g. GraphQL, chatbot, as described in the diagram at < https://github.com/christanto/sling-whiteboard/blob/master/modeling/docs/explainer.md#why-modeling >. Cheers, Christanto On Tue, Jan 8, 2019 at 6:44 PM Stefan Seifert wrote: > hello christanto. > > thanks for bringing this up! some first questions after a first read: > > 1. why defining a new "DSL" to describe the model metadata? what's with > existing things like json schema. defining a completely new DSL often has > the risk of not getting it "right" in the first place. > > 2. do you plan to support only a single resource/node and it's properties. > what's with sub tree structures, that are supported by JCR CND definitions? > more complex data models like forms are unlikely to be represented by a > single resource. or maybe that is already covered with the property > handlers although the name does not indicate it. > > 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]. this was stated a very long time ago. would be nice if you can > add a reference to your explainer page to it as well and explain why you > think different nowadays (i think there are good reasons for it, but it > always depends on the use cases). > > 4. the name "Models" can be mixed up with "Sling Models" [2] which points > somewhat into the same direction but is currently based on different > concepts and is already used much. but i suppose this can be sorted out > later to decide if this new approach can be "Sling Models 2.0" or the new > things should get a different name (like Type System). still it would make > sense to also add a reference to sling models to the explainer. > > 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? JCR CND > definitions are quite out-of-fashion nowadays, and used more for historical > reasons (or for performance optimizations because oak indexes are based on > them). the tooling around them is not good (e.g. difficult to > update/replace them in a running system). > > 6. you describe some "other models" like FormModel, ActionsModel which > sound like hypermedia support. i do not fully understand how hypermedia > support fits into the other parts you describe which primarily describe the > data model and not the actions for them. where does this hypermedia > metadata come from? > > stefan > > [1] https://wiki.apache.org/jackrabbit/DavidsModel > [2] https://sling.apache.org/documentation/bundles/models.html > > > > >-Original Message- > >From: Christanto Leonardo [mailto:christanto.leona...@gmail.com] > >Sent: Tuesday, January 8, 2019 4:03 AM > >To: dev@sling.apache.org > >Subject: Re: Sling Type System: started a wiki page for concepts, ideas, > >motivation > > > >Hello, > > > >I am currently working on the proposal to introduce the concept of > modeling > >in Sling. See it at < > >https://github.com/christanto/sling-whiteboard/tree/master/modeling>. > >One is especially encouraged to read the explainer at < > >https://github.com/christanto/sling- > >whiteboard/blob/master/modeling/docs/explainer.md > >>. > > > >My hope is that the Sling Modeling Framework can pro
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hello Stefan, Let's tackle one by one. > 4. the name "Models" can be mixed up with "Sling Models" [2] which points somewhat into the same direction but is currently based on different concepts and is already used much. but i suppose this can be sorted out later to decide if this new approach can be "Sling Models 2.0" or the new things should get a different name (like Type System). still it would make sense to also add a reference to sling models to the explainer. IMO, Sling Models should have been called "Sling POJO", as it is simply a mechanic to convert from generic API, such as Resource.class into a business-domain-friendly API. I just don't see the concept of modeling there. For "Type System", the Sling Modeling Framework is more generic than type system. I assume that type system here refers to the data definition. e.g. You define resource type `/apps/example/page` to have `title` property with String property type. Sling Modeling Framework is really for general purpose modelling, where you can model anything you like around resource (at least for now, but ideally any Adaptable). And one of the model is about data, which is defined as [DataModel] currently. Granted that Sling Models is already here, I don't know what the best way to call mine to differentiate. Cheers, Christanto [DataModel] https://github.com/christanto/sling-whiteboard/blob/08fd3637c4045470e2b2ba8f8d9bbf4fcf82c211/modeling/src/main/java/org/apache/sling/modeling/data/DataModel.java On Tue, Jan 8, 2019 at 6:44 PM Stefan Seifert wrote: > hello christanto. > > thanks for bringing this up! some first questions after a first read: > > 1. why defining a new "DSL" to describe the model metadata? what's with > existing things like json schema. defining a completely new DSL often has > the risk of not getting it "right" in the first place. > > 2. do you plan to support only a single resource/node and it's properties. > what's with sub tree structures, that are supported by JCR CND definitions? > more complex data models like forms are unlikely to be represented by a > single resource. or maybe that is already covered with the property > handlers although the name does not indicate it. > > 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]. this was stated a very long time ago. would be nice if you can > add a reference to your explainer page to it as well and explain why you > think different nowadays (i think there are good reasons for it, but it > always depends on the use cases). > > 4. the name "Models" can be mixed up with "Sling Models" [2] which points > somewhat into the same direction but is currently based on different > concepts and is already used much. but i suppose this can be sorted out > later to decide if this new approach can be "Sling Models 2.0" or the new > things should get a different name (like Type System). still it would make > sense to also add a reference to sling models to the explainer. > > 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? JCR CND > definitions are quite out-of-fashion nowadays, and used more for historical > reasons (or for performance optimizations because oak indexes are based on > them). the tooling around them is not good (e.g. difficult to > update/replace them in a running system). > > 6. you describe some "other models" like FormModel, ActionsModel which > sound like hypermedia support. i do not fully understand how hypermedia > support fits into the other parts you describe which primarily describe the > data model and not the actions for them. where does this hypermedia > metadata come from? > > stefan > > [1] https://wiki.apache.org/jackrabbit/DavidsModel > [2] https://sling.apache.org/documentation/bundles/models.html > > > > >-Original Message- > >From: Christanto Leonardo [mailto:christanto.leona...@gmail.com] > >Sent: Tuesday, January 8, 2019 4:03 AM > >To: dev@sling.apache.org > >Subject: Re: Sling Type System: started a wiki page for concepts, ideas, > >motivation > > > >Hello, > > > >I am currently working on the proposal to introduce the concept of > modeling > >in Sling. See it at < > >https://github.com/christanto/sling-whiteboard/tree/master/modeling>. > >One is especially encouraged to read the explainer at < > >https://github.com/christanto/sling- > >whiteboard/blob/master/modeling/docs/explainer.md > >>. > > > >My hope is that the Sling Modeling Framework can
RE: Sling Type System: started a wiki page for concepts, ideas, motivation
hello christanto. thanks for bringing this up! some first questions after a first read: 1. why defining a new "DSL" to describe the model metadata? what's with existing things like json schema. defining a completely new DSL often has the risk of not getting it "right" in the first place. 2. do you plan to support only a single resource/node and it's properties. what's with sub tree structures, that are supported by JCR CND definitions? more complex data models like forms are unlikely to be represented by a single resource. or maybe that is already covered with the property handlers although the name does not indicate it. 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]. this was stated a very long time ago. would be nice if you can add a reference to your explainer page to it as well and explain why you think different nowadays (i think there are good reasons for it, but it always depends on the use cases). 4. the name "Models" can be mixed up with "Sling Models" [2] which points somewhat into the same direction but is currently based on different concepts and is already used much. but i suppose this can be sorted out later to decide if this new approach can be "Sling Models 2.0" or the new things should get a different name (like Type System). still it would make sense to also add a reference to sling models to the explainer. 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? JCR CND definitions are quite out-of-fashion nowadays, and used more for historical reasons (or for performance optimizations because oak indexes are based on them). the tooling around them is not good (e.g. difficult to update/replace them in a running system). 6. you describe some "other models" like FormModel, ActionsModel which sound like hypermedia support. i do not fully understand how hypermedia support fits into the other parts you describe which primarily describe the data model and not the actions for them. where does this hypermedia metadata come from? stefan [1] https://wiki.apache.org/jackrabbit/DavidsModel [2] https://sling.apache.org/documentation/bundles/models.html >-Original Message- >From: Christanto Leonardo [mailto:christanto.leona...@gmail.com] >Sent: Tuesday, January 8, 2019 4:03 AM >To: dev@sling.apache.org >Subject: Re: Sling Type System: started a wiki page for concepts, ideas, >motivation > >Hello, > >I am currently working on the proposal to introduce the concept of modeling >in Sling. See it at < >https://github.com/christanto/sling-whiteboard/tree/master/modeling>. >One is especially encouraged to read the explainer at < >https://github.com/christanto/sling- >whiteboard/blob/master/modeling/docs/explainer.md >>. > >My hope is that the Sling Modeling Framework can provide the ability to >model many concepts in the application, starting with the typing system of >the resource (i.e. the resource type definition) as the lowest layer. > >Please let me know what you think. I plan to continue developing this >proposal. > >Cheers, >Christanto > >On 2018/10/02 11:59:08, 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+moti >vation+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> >>
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hello, I am currently working on the proposal to introduce the concept of modeling in Sling. See it at < https://github.com/christanto/sling-whiteboard/tree/master/modeling>. One is especially encouraged to read the explainer at < https://github.com/christanto/sling-whiteboard/blob/master/modeling/docs/explainer.md >. My hope is that the Sling Modeling Framework can provide the ability to model many concepts in the application, starting with the typing system of the resource (i.e. the resource type definition) as the lowest layer. Please let me know what you think. I plan to continue developing this proposal. Cheers, Christanto On 2018/10/02 11:59:08, 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> >
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hi Jason, Top-posting to sort of give a summary of my personal opinion: it's absolutely fine to experiment with new resource providers and extensions to the resource provider API. Looking forward to a discussion when we have more concrete stuff to talk about :-) Thanks, Robert On Mon, 2018-11-26 at 11:11 -0500, Jason E Bailey wrote: > I see similarities between Sling and projects such as MySql and > MongoDB. In both of these the code that actually persists the data is > a separate application, sometimes maintained by completely different > people. In the case of MySQL you had a choice between MyISAM and > InnoDB and they had different capabilities and it was up to the > needs of the administrator to determine which one to use. > > I agree with your statement that we don't build dedicated persistence > engines, but that's a very different statement to supporting the > integration of various persistence engines, and/or implementing the > layer that allows interaction with a given engine. > > I'm not sure what you were discussing, but my view of ordering comes > down to this > > 1. A Resource Provider may support ordering the children of any > particular resource > 2. It's up to an implementer to understand whether a Resource > Provider supports ordering and when it's appropriate > 3. Ordering on a merged Resource Provider results in undefined > behaviour > > Your concern with multiple providers and how the handle ordering is > valid but is an existing issue. If I have a merged view with JCR > resource provider and a non-jcr resource provider which supports > CRUD. How does that work if I add content to the non-jcr provider to > the children of an ordered jcr node? > > Of course, I'm fine with iteration, as long as we call it out that > doing X and Y isn't defined I'd move forward, but I can understand > how some would be reluctant. > > - Jason > > > > I think there's an important note to be added here. Jackrabbit/Oak > > are > > dedicated to building persistence engines. Sling is a web > > framework. I > > am not saying that we can't build persistence engines or that we > > can't > > pull up features from Oak, but that's going to be hard :-) > > > > To make things even more interesting, concerns moved at the > > resource > > provider level need to be consistent between resource providers, > > something that Oak does not have to care about. > > > > As a quick example, Radu and myself had a short chat some weeks ago > > about what it would take to add ordering at the Sling level. While > > it > > would not be _that_ hard to add some basic support at the resource > > provider level, things go downhill once you start ordering things > > between providers, e.g. > > > > - ordering fails for provider 1, succeeds for provider 2 (two-phase > > commit anyone?) > > - two providers with inconsistent ordering properties are mounted > > in > > the same sling instance
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
I see similarities between Sling and projects such as MySql and MongoDB. In both of these the code that actually persists the data is a separate application, sometimes maintained by completely different people. In the case of MySQL you had a choice between MyISAM and InnoDB and they had different capabilities and it was up to the needs of the administrator to determine which one to use. I agree with your statement that we don't build dedicated persistence engines, but that's a very different statement to supporting the integration of various persistence engines, and/or implementing the layer that allows interaction with a given engine. I'm not sure what you were discussing, but my view of ordering comes down to this 1. A Resource Provider may support ordering the children of any particular resource 2. It's up to an implementer to understand whether a Resource Provider supports ordering and when it's appropriate 3. Ordering on a merged Resource Provider results in undefined behaviour Your concern with multiple providers and how the handle ordering is valid but is an existing issue. If I have a merged view with JCR resource provider and a non-jcr resource provider which supports CRUD. How does that work if I add content to the non-jcr provider to the children of an ordered jcr node? Of course, I'm fine with iteration, as long as we call it out that doing X and Y isn't defined I'd move forward, but I can understand how some would be reluctant. - Jason > I think there's an important note to be added here. Jackrabbit/Oak are > dedicated to building persistence engines. Sling is a web framework. I > am not saying that we can't build persistence engines or that we can't > pull up features from Oak, but that's going to be hard :-) > > To make things even more interesting, concerns moved at the resource > provider level need to be consistent between resource providers, > something that Oak does not have to care about. > > As a quick example, Radu and myself had a short chat some weeks ago > about what it would take to add ordering at the Sling level. While it > would not be _that_ hard to add some basic support at the resource > provider level, things go downhill once you start ordering things > between providers, e.g. > > - ordering fails for provider 1, succeeds for provider 2 (two-phase > commit anyone?) > - two providers with inconsistent ordering properties are mounted in > the same sling instance
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
On Wed, 2018-10-10 at 10:09 -0400, Jason E Bailey wrote: > On Wed, Oct 10, 2018, at 8:36 AM, Robert Munteanu wrote: > > > I think that's an important point, this should live on the Sling > > level. > > For the sake of being complete, there are also Oak restrictions > > that > > sort of overlap the scope of this initiative, see for instance [1]. > > > This is a side note. > > This brings up a point that I've been formulating around the > relationship of sling and the JCR. Which is similar to the discussion > that's been occurring with security. > > For historical perspective, Sling has passed responsibility for > certain concepts to the JCR such as types and security. Going forward > because there is a need for resource providers other than the JCR, it > makes sense to move these concepts upwards into the Sling layer. I think there's an important note to be added here. Jackrabbit/Oak are dedicated to building persistence engines. Sling is a web framework. I am not saying that we can't build persistence engines or that we can't pull up features from Oak, but that's going to be hard :-) To make things even more interesting, concerns moved at the resource provider level need to be consistent between resource providers, something that Oak does not have to care about. As a quick example, Radu and myself had a short chat some weeks ago about what it would take to add ordering at the Sling level. While it would not be _that_ hard to add some basic support at the resource provider level, things go downhill once you start ordering things between providers, e.g. - ordering fails for provider 1, succeeds for provider 2 (two-phase commit anyone?) - two providers with inconsistent ordering properties are mounted in the same sling instance --- Again, not saying that we should not do it, just that we have to be careful about how to do it. And that it would make sense to keep what have in Oak, as it's been used over and over and battle-tested. Thanks, Robert > > This now introduces an issue where, at a high level, we have two > different ways of doing 'x'. > > Options > 1. Leave the way of implementing of 'x' to the resource provider. > With Sling providing a failover way of handling it if the resource > provider doesn't > 2. Make all new resource providers provision it the Sling way. > Leaving the jcr oak implementation alone. > 3. Make the Sling way, the official way, and eventually all resource > providers, including the jcr oak resource provider must support the > sling way of doing things. > > IMHO, the third option is the way to go. >
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
On Wed, Oct 10, 2018, at 8:36 AM, Robert Munteanu wrote: > I think that's an important point, this should live on the Sling level. > For the sake of being complete, there are also Oak restrictions that > sort of overlap the scope of this initiative, see for instance [1]. > This is a side note. This brings up a point that I've been formulating around the relationship of sling and the JCR. Which is similar to the discussion that's been occurring with security. For historical perspective, Sling has passed responsibility for certain concepts to the JCR such as types and security. Going forward because there is a need for resource providers other than the JCR, it makes sense to move these concepts upwards into the Sling layer. This now introduces an issue where, at a high level, we have two different ways of doing 'x'. Options 1. Leave the way of implementing of 'x' to the resource provider. With Sling providing a failover way of handling it if the resource provider doesn't 2. Make all new resource providers provision it the Sling way. Leaving the jcr oak implementation alone. 3. Make the Sling way, the official way, and eventually all resource providers, including the jcr oak resource provider must support the sling way of doing things. IMHO, the third option is the way to go.
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
On Wed, 2018-10-10 at 14:20 +0200, Bertrand Delacretaz wrote: > On Wed, Oct 10, 2018 at 2:12 PM Jason E Bailey > wrote: > ... > > 1. If a resource does not declare a type is there a default one? > > ... > > I don't have an opinion on this so far. > > > 2. How does the sling type differ from the jcr node types and how > > will they co-exist? > > I think the Sling Type System should be independent from JCR, to be > able to run on various storage backends. I think that's an important point, this should live on the Sling level. For the sake of being complete, there are also Oak restrictions that sort of overlap the scope of this initiative, see for instance [1]. Thanks, Robert [1]: https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
On Wed, Oct 10, 2018 at 2:12 PM Jason E Bailey wrote: ... > 1. If a resource does not declare a type is there a default one? ... I don't have an opinion on this so far. > 2. How does the sling type differ from the jcr node types and how will they > co-exist? I think the Sling Type System should be independent from JCR, to be able to run on various storage backends. -Bertrand
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
On Wed, Oct 10, 2018, at 5:54 AM, Bertrand Delacretaz wrote: > On Tue, Oct 9, 2018 at 6:34 PM Jason E Bailey wrote: > Good point, I think it's analogous to casting an object in Java and > should be subject to similar rules. Or how interfaces work in golang where you just need to meet the field requirements. Questions 1. If a resource does not declare a type is there a default one? 2. How does the sling type differ from the jcr node types and how will they co-exist?
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
On Tue, Oct 9, 2018 at 6:34 PM Jason E Bailey wrote: > ...in the RequestDispatcherOptions which is used by the sling:include taglib, > you can force an overwrite of a resourceType to something else... Good point, I think it's analogous to casting an object in Java and should be subject to similar rules. I have added a "Notes from other discussions" section with this note at https://cwiki.apache.org/confluence/display/SLING/Sling+Type+System%3A+motivation+and+requirements -Bertrand
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
On Tue, Oct 9, 2018, at 8:46 AM, Bertrand Delacretaz wrote: > Not sure what you mean by "apply other resourceTypes", do you mean by > changing the sling:resourceType property? > Specifically, in the RequestDispatcherOptions which is used by the sling:include taglib, you can force an overwrite of a resourceType to something else. Which is amazingly useful, but I wanted to point that out specifically, since I'm not changing the property. I'm changing what is used in the resourceType resolution.
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hi Jason, On Wed, Oct 3, 2018 at 2:44 PM Jason E Bailey wrote: > ...A resource can have a sling:resourceType which defines the process which > processes the resource. That is the default process, however > you can apply other resourceTypes to that resource so it's processed > differently based on your need Not sure what you mean by "apply other resourceTypes", do you mean by changing the sling:resourceType property? Then ok, you can do that now and as you say the scripts and servlets wired to the new resource type will do their best to handle it. > ...By assigning types to the resourceType you can define required/optional > fields and the types of actions that can occur on that resource... Yes that's the idea. > > This will then give you the ability to do the following > 1. generate meta data about the resource for use with a UI > 2. potentially used as a field validation if someone attempts to create a > resource type without the proper fields > 3. Will generate an error if they use something like sling:include to > override the default resourceType and the new resourceType requires > properties that the resource doesn't have Yes, sounds reasonable! -Bertrand
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Let me see how close I am to your thought process. A resource can have a sling:resourceType which defines the process which processes the resource. That is the default process, however you can apply other resourceTypes to that resource so it's processed differently based on your need. To me that makes it more like an OO interface. Right now, you can apply any resourceType to any resource and it will attempt to handle it. Even if the values on the resource that the resourceType requires aren't there. By assigning types to the resourceType you can define required/optional fields and the types of actions that can occur on that resource. This will then give you the ability to do the following 1. generate meta data about the resource for use with a UI 2. potentially used as a field validation if someone attempts to create a resource type without the proper fields 3. Will generate an error if they use something like sling:include to override the default resourceType and the new resourceType requires properties that the resource doesn't have. How am I doing? - Jason On Tue, Oct 2, 2018, at 10:15 AM, Bertrand Delacretaz wrote: > Hi Jason, > > thanks for your feedback! > > On Tue, Oct 2, 2018 at 3:48 PM Jason E Bailey wrote: > > ...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... > > Yes, among other things including some that we might discover along the way. > > > ...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 > > Absolutely, which means we can generate hyperlinks for such operations > automatically. > > >... 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?... > > I think actions can be more specific, at least in terms of their > link:rel values. > > A hyperlink can say > > link:rel=sling.create.imagefolder, method=POST, path=./images > > as basically it, along with the Sling Type System (STS) typedef, needs > to contain enough information to generate an HTML form when generating > a UI. > > maybe...just thinking outloud, but basically an action can have a more > specific name than POST to clarify what it does exactly. > > > ...Looking at the code, I get confused between a type for a resource and a > > sling:resourceType. I believe these are different things > > I think it's fair to describe the code as a hack created when those > ideas where still emerging ;-) > > My point of view is that a resourceType points to an STS typedef, > which conceptually points to rendering scripts or servlets. > > That's conceptually...in practice I think we can keep the current > script resolution mechanism, but the STS typedef might validate > operations before passing them on. > > Does that address your concerns? > > That's all still vague for now anyway, needs to be defined more > clearly and proven with prototypes. > > -Bertrand
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
Hi Jason, thanks for your feedback! On Tue, Oct 2, 2018 at 3:48 PM Jason E Bailey wrote: > ...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... Yes, among other things including some that we might discover along the way. > ...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 Absolutely, which means we can generate hyperlinks for such operations automatically. >... 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?... I think actions can be more specific, at least in terms of their link:rel values. A hyperlink can say link:rel=sling.create.imagefolder, method=POST, path=./images as basically it, along with the Sling Type System (STS) typedef, needs to contain enough information to generate an HTML form when generating a UI. maybe...just thinking outloud, but basically an action can have a more specific name than POST to clarify what it does exactly. > ...Looking at the code, I get confused between a type for a resource and a > sling:resourceType. I believe these are different things I think it's fair to describe the code as a hack created when those ideas where still emerging ;-) My point of view is that a resourceType points to an STS typedef, which conceptually points to rendering scripts or servlets. That's conceptually...in practice I think we can keep the current script resolution mechanism, but the STS typedef might validate operations before passing them on. Does that address your concerns? That's all still vague for now anyway, needs to be defined more clearly and proven with prototypes. -Bertrand
Re: Sling Type System: started a wiki page for concepts, ideas, motivation
+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
