jPDL 4 early feedback

[tom.baeyens]

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

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

Early feedback is welcome.

[tom.baeyens]

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.

[heiko.braun]

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.

[heiko.braun]

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.

[heiko.braun]

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?

[tom.baeyens]

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.

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.

[tom.baeyens]

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 ?

[kukeltje]

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

[camunda]

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...

[camunda]

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...

[heiko.braun]

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

Why?

[camunda]

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...

[heiko.braun]

Hm, I see. That may probably be right.

[kukeltje]

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....

[tom.baeyens]

"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.