1 2 3 Previous Next 42 Replies Latest reply on Jul 2, 2008 6:35 AM by Tom Baeyens

    jPDL 4 early feedback

    Tom Baeyens Master

      I have outlined the initial scope and schema for jPDL 4.

      http://docs.jboss.com/jbpm/jpdl4/doc/xsd/

      Early feedback is welcome.

        • 1. Re: jPDL 4 early feedback
          Tom Baeyens Master

          Notice that there are some TODO's in the namespace overview page (at the bottom). Ideas on those todo's are also welcome.

          I might highlight those TODO's later here in the forum as separate posts.

          • 2. Re: jPDL 4 early feedback
            Heiko Braun Master

            I am wondering why the schema contains element declarations for concrete activities like 'email'. IMO we shouldn't treat the stock activities anyhow different as the ones user supply. That means they wouldn't be represented by an element name on it's own.

            • 3. Re: jPDL 4 early feedback
              Heiko Braun Master

              On the other hand, if we move stock activities to a custom namespace, then they are separated from the core xsd constructs. By the same means users could introduce their own namespaces: Let say you provide an XSD with custom activities for inclusion and your activities derive from a base type, then people could do do something like:

              <process-definition>
               <xmlns="http://foo.bar.com/order/v1" creditcardVerification/>
              </process-definition>
              


              Whereas creditcardVerfification derives from http://jbpm.org/jpdl-4:activity.

              • 4. Re: jPDL 4 early feedback
                Heiko Braun Master

                From the schema doc is kind of hard see the big picture. Can we come up with some example xml files? To see how concrete process definitions look like?

                • 5. Re: jPDL 4 early feedback
                  Tom Baeyens Master

                   

                  "heiko.braun@jboss.com" wrote:
                  I am wondering why the schema contains element declarations for concrete activities like 'email'. IMO we shouldn't treat the stock activities anyhow different as the ones user supply. That means they wouldn't be represented by an element name on it's own.


                  jPDL is an executable process language. Each node is of a certain type. One node type will delegate to an activity implementation (== direct mapping to the PVM construct). Another node type will call a java method through running a script or evaluating an expression. Other node types do more functional behaviour like email.

                  Separating the structure from the activity behaviour would make the XML a lot more verbose and hence less readable.

                  "heiko.braun@jboss.com" wrote:
                  On the other hand, if we move stock activities to a custom namespace, then they are separated from the core xsd constructs.


                  using separate namespaces for user defined node types is certainly something that i think should be possible.

                  but a whole process should be usable without namespaces as well, i think. just referencing the core jpdl xsd in the default namespace is simple. so that should never be a problem.

                  but combining namespaces is what always should be optional. meaning. the functionality should always be available with or without setting up the namespaces properly.

                  so when users want to add a new node type, i don't want them to be forced to write an xsd and configure the namespace in the process.

                  • 6. Re: jPDL 4 early feedback
                    Tom Baeyens Master

                     

                    "heiko.braun@jboss.com" wrote:
                    From the schema doc is kind of hard see the big picture. Can we come up with some example xml files? To see how concrete process definitions look like?


                    yes. i thought of building out examples as i implemented the nodes. but it's probably wise to provide a few example jpdl files up front.

                    a set of wiki pages ?

                    do i just put them in the old wiki, or is it more convenient if i start building those pages in the new wiki directly ?

                    • 7. Re: jPDL 4 early feedback
                      Ronald van Kuijk Master

                       

                      so when users want to add a new node type, i don't want them to be forced to write an xsd and configure the namespace in the process.


                      I do not realy see a problem with this. If they can create their own node types I bet they fairly easy make their own xsd, certainly if we provide an example



                      • 8. Re: jPDL 4 early feedback
                        Bernd Ruecker Master

                        Ah, the namespace discussion again :-)

                        I agree with Tom, jPDL should be usable without any namespaces and even without the people knowing what namespaces are...

                        • 9. Re: jPDL 4 early feedback
                          Bernd Ruecker Master

                           

                          yes. i thought of building out examples as i implemented the nodes. but it's probably wise to provide a few example jpdl files up front.
                          a set of wiki pages ?


                          Yeah, would be much better. From a set of examples it is easy to catch the syntax...

                          • 10. Re: jPDL 4 early feedback
                            Heiko Braun Master

                             


                            I agree with Tom, jPDL should be usable without any namespaces and even without the people knowing what namespaces are...


                            Why?

                            • 11. Re: jPDL 4 early feedback
                              Bernd Ruecker Master

                              Much easier for non XML gurus...

                              Don't underestimate the advantage gained, because Java developer without any deeper XML or WS knowledge can just start with jPDL, without bothering about namespaces...

                              • 12. Re: jPDL 4 early feedback
                                Heiko Braun Master

                                Hm, I see. That may probably be right.

                                • 13. Re: jPDL 4 early feedback
                                  Ronald van Kuijk Master

                                   

                                  I agree with Tom, jPDL should be usable without any namespaces and even without the people knowing what namespaces are...


                                  Sure, but without any extensions.... So basic jPDL... otherwise (imnsho) validation, code completion etc will be much harder.

                                  Even if we just make sure there is an allow any attribute in another namespace without requiring validation for it, people do not have to make xsd's but do have to use a custom namespace.... I keep saying that if people are that intelligent to use and extend jBPM, that have the knowledge, well, intelligence to at least understand the basics of namespaces....

                                  • 14. Re: jPDL 4 early feedback
                                    Tom Baeyens Master

                                     

                                    "kukeltje" wrote:
                                    I keep saying that if people are that intelligent to use and extend jBPM, that have the knowledge, well, intelligence to at least understand the basics of namespaces....


                                    I don't agree with this. I believe that has been the power.

                                    Each time when I have to mess with namespaces there is at least some struggle in getting it to work properly:

                                    * default versus prefixed namespace
                                    * resolution of the xsd is always a problem as we want to publish it online, but we want all to run ok without internet connection. so we need to provide the xsd as a resources as well. then resolution of how it finds the xsd becomes non trivial and has to do with catalogue configuration and things like that.
                                    * elementFormDefault and attributeFormDefault. i've struggled a lot with those and still not get all the possible combinations

                                    this will make it a lot more difficult to plug in custom event listeners or activity types.

                                    ...and i'm not saying that we should ditch schema and namespaces. i'm only saying it's a requirement that it should also work without validation and namespaces.

                                    1 2 3 Previous Next