[tom.baeyens]

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

That developers can just write a process without knowing the schema namespace reference and how to apply that. E.g. in unit tests it is not really practical if you're forced to refer the namespace.

I don't think we should be dogmatic with schema validation. As that only validates a subset of all the constraints and validations. When parsing the process file, there are always a lot of things that can only be checked at parse time and that cannot be checked with the schema. So schema validation can not give you full coverage anyway.

In the current parsing, the schema validation errors are collected and reported in a similar way as the (typically more complex) validation errors detected during interpretation of the DOM and build up of the process model. This way the designer will be able to show all the problems in the problem view one day.

[koen.aers]

What is the outcome of this discussion now?

Is there a 'gpd' namespace or not?

Do I use the attribute 'g' and encode all the information I need in there to keep the language simple or do I use a verbose set of elements in which all the graphical information is rather explicit?

Tom and I opted for the simplicity (meaning a 'g' attribute in the 'jpdl' namespace) which has been one of our assets until now. Later on, and if needed, we would always be able to add more advanced constructs.

Regards,
Koen

[tom.baeyens]

definitely not introduce a gpd namespace... ha... haaa... HATCHOU !

for this alpha 1 release, a jpdl 4 namespace reference is it's not yet a must. we can postpone that. let's look at this on friday.

does this have more impact then just updating the template used in the new jPDL 4 process wizard ?

[aguizar]

Jamming all GPD properties in a single attribute seems quite complex to me. How about a nested optional element in the jPDL namespace to contain the GPD properties separately? For example:

<state>
 <gpd width="100" length="100" color="fuschia" />
</state>

Advantages:
* Because the gpd element is optional, there is no need for a separate GPD namespace.
* You do not need to jam different GPD properties in a single attribute.
* The contents of the gpd element can be described in a schema, so you get code completion and validation at parsing time. This is not possible with a single attribute.

[aguizar]

A note to my previous post: with "quite complex" I meant inelegant, hard to read and not amenable to validation. Not complex to implement.

[thomas.diesler]

Metadata that is not directly related to description of the process should not leak into the jPDL namespace. Instead, a seperate namespace should be used for these orthogonal concerns.

[kukeltje]

I agree (mostly) with Alex, *not* jam it into one attribute... yuck... the thought alone makes me...... you know...... the feeling you get if you drink to much Dutch beer

I agree with Thomas. GPD info should *not* leak into the jpdl namespace.

<state name="a state">
 <gpd:layout x="10" y="20" width="100" height="100" colour="fuchsia"/>
</state>

[estaub]

Metadata that is not directly related to description of the process should not leak into the jPDL namespace. Instead, a seperate namespace should be used for these orthogonal concerns.

+1