JBossDeveloper

+1

The standard JAXP attribute http://java.sun.com/xml/jaxp/properties/schemaSource lets you specify schemata to be considered while parsing XML, without entering in the whole catalog stuff. Likewise, the Xerces attribute http://apache.org/xml/features/validation/dynamic tells the parser to validate the document only if a schema is specified. Together, these two attributes allow the parser to work offline and validate only those elements whose schema is available.

Working without namespaces is a matter of setting either the default namespace or the xsi:noNamespaceSchemaLocation attribute right. Should not be an obstacle to a solution based on namespaces.

I believe we should have a validating parser all the time. This would have two benefits:

* the jPDL parser would be simpler because it would not have to concern itself with checking constraints that are already expressed in the schema document.

* error reporting to users would be better, because we can capture the syntax error list from the XML parser and return it along the semantic errors detected by the jPDL parser.

On the other hand I understand that users that always enter schema-valid documents (such as those produced by the designer) would want to save the overhead of validation. The configurable XML parser that you propose would be the solution there.

A separate validation step is less useful in my view, because it adds more overhead compared to the validate-as-you-parse approach.

What's the point in having a schema at hand but then skip the validation? I mean that's what it's all about.

However I think this discussion was about the xml "language" we use for jdpl 4 . So let's get back to that discussion and leave the implementation details for now.

So let's get back to that discussion and leave the implementation details for now.

Stock versus custom activities

IMO stock activities like "email" shouldn't be treated different then activities that users supply. I would prefer one way of defining activities in jpdl4 and not begin with a set of special cases. Simplicity is something that I always hear in this forum, but IMO defining extra tags for "some" activities and a different schema for others makes it more complex and not any more simple.

I think the question is where to draw the line?
The way I see it, there is control flow activities and use case activities. The later would be "email somebody" or "forward the message to an ESB" type of extensions. To me it looks like being implemented as an activity is more like an implementation detail to the control flow ones and can easily be hidden behind a custom xml dialect, but the use case activities should be treated equally, regardless if they are prebuild ones, or extensions that users supply.

I see it like convience methods: Easier and faster to use, so it is very handy to have these node types. And Email is something everybody normally asks for.

And: I think it cannot be removed, it is already in jPDL 3, so it should stay like it is...

I would even like some more special nodes (liKe ESB and WS-Integration). Okay, where to draw the line is really the interessting question then...

Maybe it helps if we regard jpdl4 with the core bpm constructs in mind for now. Control flow activities that is. I think this part needs to be stable before being released whereas use case activities are more likely subject to change and can easily be added along the way.

Let's do an example: We ship a stock "email" activity that's being represented by an email element in schema. Later on someone contributes an FTP activity to jBPM. At that point we already have stock activities being treated differently, because we cannot simply change the jpdl4 schema.

If we use one way to express extension points, and that's equal to both stock and custom extension, then we don't run into this problem.

Basically I am trying to get to the point where we have a clear way of extending jdpl4. Both for jpdl4 developers as well as users.

And: I think it cannot be removed, it is already in jPDL 3, so it should stay like it is...

Heiko, I don't agree with this.

I believe that your arguments are correct, but in the scope of the PVM: in the PVM there shouldn't be any custom things, only activities without further notice.

But JPDL is a language built upon this PVM. The point of the PVM is to *allow* customizations like the JPDL DSL. JPDL tries to be an all-around business process language. Mailing is something that is needed in many BPM use cases, so I believe it's only natural to take in account the mailing activity.

I do agree that JPDL custom nodes must have boundaries, but mailing & sending a message to an ESB are such common BPM concepts, that they should be implemented in the language and not for every BPM project again and again.

mailing & sending a message to an ESB are such common BPM concepts, that they should be implemented in the language and not for every BPM project again and again.

Custom one:
<activity class="org.foo.bar.SMS"/>

Stock one:
<activity class="org.jbpm.activities.Email"/>

Stock one in 4.0:
<email/>

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

Heiko,

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

The option you propose is indeed more stable concerning the schema when stuff is implemented in newer versions of jBPM. I do like this approach very much (it reminds me of Spring ;-)

My only concern is with the GPD: how hard will it be to maintain these new 'stock' activities?

Okay, another proof that examples are very important :-)

I think it may be a good idea, I have two concerns:
- The Designer has to be able handle it
- It is less readable if you write the process by hand (what a lot of people do). I wouldn't underestimate that argument.

At least I would vote for something like this:

<activity type="FTP"/>