1 2 Previous Next 22 Replies Latest reply on Nov 25, 2008 4:45 PM by Edward Staub

    comments on initial xsd jpdl 4

    Ronald van Kuijk Master

      - tns namespace-prefix should be jpdl
      - g as an attribute for gpd info will not work. This should be a complex element in its own namespace and allowed under each jpdl element. Maybe there should be more/different gpd elements (transitions need other info than nodes). So either leave it out completely (for now) or do it a little more right

        • 1. Re: comments on initial xsd jpdl 4
          Tom Baeyens Master

          we discussed exactly the topic element vs attribute a full hour yesterday. and we swinged back and forth between element and attribute.

          we looked into various bpmn modellers to see what kind of information they had apart from the
          * diagram size
          * activity box bounds coordinates, width and height
          * transition/flow anchor points and bendpoints

          it turned out to be only color and font in activities. therefor we think it should not be made extensible. and we thought about what the scope was of our graphical designer efforts.

          g is only for the gpd. other extensions should go into their own extension element / attribute.

          maybe we should even not put the g declaration in the xsd and cause every element should have an anyAttribute declaration for extensibility.

          does this reasoning make sense to you as well ?

          • 2. Re: comments on initial xsd jpdl 4
            Thomas Diesler Master

            Yes, a general extension mechanism should be put in place that allows the GPD and other consumers of the jPDL to extend the definition in an appropriate way.

            GPD concerns should not leak into the jPDL XSD

            • 3. Re: comments on initial xsd jpdl 4
              Ronald van Kuijk Master

               

              "tom.baeyens@jboss.com" wrote:
              we discussed exactly the topic element vs attribute a full hour yesterday. and we swinged back and forth between element and attribute.

              we looked into various bpmn modellers to see what kind of information they had apart from the
              * diagram size
              * activity box bounds coordinates, width and height
              * transition/flow anchor points and bendpoints

              Where is this info going then?

              "tom.baeyens@jboss.com" wrote:
              does this reasoning make sense to you as well ?


              No, since it does not say where the other info is going....

              • 4. Re: comments on initial xsd jpdl 4
                Ronald van Kuijk Master

                 

                "thomas.diesler@jboss.com" wrote:
                Yes, a general extension mechanism should be put in place that allows the GPD and other consumers of the jPDL to extend the definition in an appropriate way.

                GPD concerns should not leak into the jPDL XSD


                Funny, this latter remark is a 180 degree turn from what was initially the idea. Making one jpdl file with process and graphical info in it instead of having to keep two files in sync. The 'general extension machanism' is using good extensionpoints in the xsd.

                • 5. Re: comments on initial xsd jpdl 4
                  Tom Baeyens Master

                   

                  "kukeltje" wrote:
                  "tom.baeyens@jboss.com" wrote:
                  we discussed exactly the topic element vs attribute a full hour yesterday. and we swinged back and forth between element and attribute.

                  we looked into various bpmn modellers to see what kind of information they had apart from the
                  * diagram size
                  * activity box bounds coordinates, width and height
                  * transition/flow anchor points and bendpoints

                  Where is this info going then?

                  "tom.baeyens@jboss.com" wrote:
                  does this reasoning make sense to you as well ?


                  No, since it does not say where the other info is going....


                  The only other info that we consider inside the scope of what we target might be color (although definitely not in the first releases). And we concluded that can always be encoded within the text field as only the designer has to manage it.

                  • 6. Re: comments on initial xsd jpdl 4
                    Tom Baeyens Master

                     

                    "kukeltje" wrote:
                    "thomas.diesler@jboss.com" wrote:
                    Yes, a general extension mechanism should be put in place that allows the GPD and other consumers of the jPDL to extend the definition in an appropriate way.

                    GPD concerns should not leak into the jPDL XSD


                    Funny, this latter remark is a 180 degree turn from what was initially the idea. Making one jpdl file with process and graphical info in it instead of having to keep two files in sync. The 'general extension machanism' is using good extensionpoints in the xsd.


                    i wouldn't consider this a 180 degrees turn :-)

                    but if i understand you correct, you do have a point: we could as well leave the 'g' attributes out of the specified schema and leave it up the the designer to add this as one of the anyAttributes.

                    that is something we did not consider yet. and at first thought it makes sense to me as then the g attribute won't be offered in code completions to developers writing xml by hand.

                    what do you think of that, Koen ?

                    • 7. Re: comments on initial xsd jpdl 4
                      Ronald van Kuijk Master

                       


                      i wouldn't consider this a 180 degrees turn :-)
                      If you take jBPM 3 'as is' it isn't :-)


                      The only other info that we consider inside the scope of what we target might

                      This is where we might see things differently, or to be more precise, I do not see anything at all :-)

                      The other info I was talking about was location, size etc... where does that 'designer' info go to?

                      Regarding the extension mechanism, you propbably misunderstood me. I do not think 'g' should be left out in the xsd. Au contraire... it should be more specific (you know, namespaces ;-))

                      • 8. Re: comments on initial xsd jpdl 4
                        Tom Baeyens Master

                        we store all coordinates or bendpoints in attribute g. but i don't know what you mean with location and size.

                        as it is now g is the jpdl namespace.

                        • 9. Re: comments on initial xsd jpdl 4
                          Edward Staub Expert

                           

                          "kukeltje" wrote:

                          you know, namespaces ;-))


                          You don't want Tom to get the hives - you know about his allergy to namespaces ;-)

                          Seriously - as I see it, this is a clear case for using a namespace. I think there's a good chance another editor might come along, with a different persistent dataset to merge in.

                          -Ed


                          • 10. Re: comments on initial xsd jpdl 4
                            Koen Aers Master

                            So the attribute name would be g and the namespace gpd?

                            • 11. Re: comments on initial xsd jpdl 4
                              Tom Baeyens Master

                              fyi, i don't have an allergy to namespaces.

                              i want both to be possible: specify a namespace and then the process gets validated. or don't specify a namespace and your process will not get validated.

                              @Koen: i want only 1 namespace for jpdl and 1 for the configuration file. i don't want process files with multiple prefixes.

                              If you set the default namespace to jpdl, no element or attribute defined by us should have a prefix.

                              • 12. Re: comments on initial xsd jpdl 4
                                Ronald van Kuijk Master

                                @Koen,

                                Yes, or better, if g only will contain 'color' than not why name it color?

                                @Ed, you see... just like with real allergies... give the person little bits of the allergent (?) a large number of times, spread over time and the allergy automagically disappers.... They even think they were never allergic to it at all... LOL....

                                @Tom: Yes, the deafult namespace used should be jpdl which will not require prefixes then...

                                • 13. Re: comments on initial xsd jpdl 4
                                  Thomas Diesler Master

                                  what is the advantage of being able to deploy a potentially invalid (i.e. not validated) process definition?

                                  • 14. Re: comments on initial xsd jpdl 4
                                    Ronald van Kuijk Master

                                    Sorry.. Yes, I forgot to comment on that as well... Currently the reason is kind of not neat. The xsd was not always in line with the parser, so if you wanted certain functionality, you could remove the namespace declaration from the processdefinition and xsd validating was turned off. Imo, this should not happen in jBPM 4 (nor should it have been in 3, just a lack of time to keep all in sync, including docs)

                                    So personally, I'd opt for not accepting a processdefinition if there is no namespace declaration, OR assume the latest and still validate.

                                    1 2 Previous Next