[heiko.braun]

Now I see your point, my apologies for the misunderstanding.

NP. Currently I am just brainstorming.

[estaub]

Is the XSD itself available?
Because it's so much more concise than javadoc, it's easier to see the big picture with the XSD - especially if you have good schema-viewing software.

[estaub]

Is the XSD itself available?
Because it's so much more concise than javadoc, it's easier to see the big picture with the XSD - especially if you have good schema-viewing software.

[kukeltje]

If we cannot extend the schema within minor releases we'll something like this soon:

Stock one in 4.0:
<email/>

Stock one in 4.1:
<activity class="org.jbpm.activities.FTP"/>

This already happend in 3. We have a

<mail name="send mail">
..
</mail>

and

<node name="esb1>
 <action class=org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler">
 .... (params)
 </action>
</node>

The reason here was that the jBPM and the GPD could be extended by a ESB configuration pane without changing the core...

<activity type="FTP"/>

should be possible by using 'refs' to generic actionhandlers (sorry, not used to the pvm wordings). Maybe even to generic refs whose implementations are in the core and do not have to be configured in the processdefinition.

Still, for me mail, esb etc should not be specific nodes since they are not for the control flow....

[kukeltje]

'the' xsd is not available yet... for the very reason this discussion is taking place.... it has to be defined based on input from us.

[aguizar]

The problem with this kind of syntax:

<activity type="mail"/>

is that you can't define a schema anymore. The content type of the activity element has to allow any element.

One solution is to use nested subelements:

<activity>
<mail to='boss' />
</activity>

However, this is verbose and makes the process definition less readable.

WS-BPEL solved this by having a number of stock activities like:

<bpel:invoke operation="selfdestruct" />

and providing a placeholder for extension activities:

<bpel:extensionActivity>
 <jbpm:mail to='boss' />
</bpel:extensionActivity>

The BPEL approach may be worth considering here.

@Heiko: the earlier posts were about skipping validation for user-defined extension items whose schema was unavailable. Just FYI.

[estaub]

"kukeltje" wrote:
'the' xsd is not available yet... for the very reason this discussion is taking place.... it has to be defined based on input from us.

Er... the javadoc was generated by a tool that converts an xsd to javadoc. To see the big picture, the original xsd would be useful. It can be stamped "first draft" in many ways, so that it is not confused with the final.

[tom.baeyens]

<activity name="s" class="com.customer.OurSapIntegration">
 <field name="server"><string value="sap.intranet.customer.com"/></field>
 <transition to="next" />
</activity>

can be given a shortcut like this

<sap name="s" server="sap.intranet.customer.com">
 <transition to="next" />
</sap>

to improve readability.

Additions (including introduction of shortcuts like these) can even be done in micro version updates as they don't break existing backwards compatibility.

The esb node was a special case and such quick-fixes must be avoided in the future. The biggest problem with the esb node is that the action handler was located in the esb jar and not in the jbpm-jpdl jar. That way incompatibilities appeared between (jbpmruntime+designer) and (esbnode)

Also, there can be dependencies of activity implemenetations on certain configurations on the node structure properties. For example, a sequence implementation might require that the isPreviousNeeded property is set on the node. Such things further complicate the reading and writing process XML by hand.

The good part of the PVM is that the upper xml example snippet will become persistable in the generic PVM DB schema.

[heiko.braun]

Some background information on schema design that may be useful for this thread:

* http://www.xml.com/pub/a/2004/07/21/design.html
* http://www.xml.com/pub/a/2003/12/03/versioning.html

[heiko.braun]

Another good one:

* http://www.tbray.org/ongoing/When/200x/2006/01/09/On-XML-Language-Design

[tom.baeyens]

perfect lecture for during the holidays. i'll surely find some time to read them during the next two weeks.

[koen.aers]

As far as the designer is concerned: for the current implementation it is indeed very difficult to add new stock nodes. Hence also the 'quick' implementation using generic nodes for the ESB node.

For the future version of the GPD, this limitation should and will be ironed out.

Regards,
Koen

[tom.baeyens]

"estaub" wrote:
Is the XSD itself available?
Because it's so much more concise than javadoc, it's easier to see the big picture with the XSD - especially if you have good schema-viewing software.

i've published it for your convenience

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