Bug 375359 - targetNameSpace missing when saving bpmn2 model
Summary: targetNameSpace missing when saving bpmn2 model
Status: NEW
Alias: None
Product: MDT.BPMN2
Classification: Modeling
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-26 15:45 EDT by loic Missing name CLA
Modified: 2012-03-30 07:56 EDT (History)
0 users

See Also:


Attachments
Generated bpmn file with missing targetNameSpace and duplicated property IDs (26.51 KB, application/octet-stream)
2012-03-26 15:47 EDT, loic Missing name CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description loic Missing name CLA 2012-03-26 15:45:56 EDT
Build Identifier: Build Identifier: 0.7.0.201203160619 (also using bpmn2-modeler 0.0.1.201203161937)

Note:  I used bpmn2-modeler to build the model and save it.  Although my understanding is that bpmn2-modeler is using mdt/bpmn2 for the model and XML save, let me know if I need to redirect this issue to the bpmn2-modeler project.

We tried to validate the bpmn2 file generated from a model, and we found a couple of issues (see attachment application.bpmn):

1. In the Definition is missing the targetNameSpace. 
   Note: This might be linked to Bug 373502.

2. I have been able to create duplicated property IDs, which should not be allowed.



Reproducible: Always

Steps to Reproduce:
The attachment has been generated by bpmn2-modeler (using mdt/bpmn2).  It does miss the targetNameSpace and has several duplicated property IDs.
Comment 1 loic Missing name CLA 2012-03-26 15:47:58 EDT
Created attachment 213193 [details]
Generated bpmn file with missing targetNameSpace and duplicated property IDs
Comment 2 Henning Heitkoetter CLA 2012-03-28 09:50:29 EDT
1. targetNamespace is a required attribute - in earnest, not just by mistake as in bug 373502 :)
Hence, the behavior of the validator is correct. If no targetNamespace is set, validation should fail. The specification defines no default value, because the target namespace defines the virtual location of all elements contained in the model, similar to a package in Java, and should be set by the user, not by the modeling tool.

2. As I see it, these duplicate IDs are correctly reported as validation errors.
I'm a little hesitant wrt patronizing the user, so I would not want to restrain him from (perhaps temporarily) entering duplicate IDs or creating and saving an otherwise invalid model. However, we might want to report these errors automatically (triggered on save), not only when the user manually validates the model. But even if validation fails, the editor should still allow the user to save his model.
Comment 3 loic Missing name CLA 2012-03-29 18:23:50 EDT
1. targetNamespace:
From a user experience point of view, would you consider putting a default targetNamespace (even though the standard does not provide one), so the creation of a brand new diagram is valid diagram ?
Not a big issue, but it feels a bit strange that by default the tool generates a non-valid diagram (i.e. with an empty targetNamespace).  And first thing a user have to do with a new diagram is to set the targetNamespace.  If you feel that is the way to go, I am fine with it.  I could ask to the bpmn2-modeler new BPMN2 Diagram wizard to require a targetNamespace before creating the diagram...

2. duplicate IDs:
I am okay with letting the user write (temporarily) duplicate IDs.  Marking the errors would be good.  I am less happy to let users save it with errors, because I feel that the tool should generate valid diagrams... but I do see in Eclipse examples (e.g. JDT) where I can save files even with errors, so I guess users should not be surprised with this behaviour.

Thanks!
Comment 4 Henning Heitkoetter CLA 2012-03-30 07:56:51 EDT
1. Prompting the user for a target namespace would be my preferred approach. We could do the same in our New BPMN2 Model Wizard. This way, the user is made aware that he has to provide a target namespace.
I think the standard has good reasons not to provide a default value, because it would likely lead to most BPMN models using the same namespace, while this attribute is intended to be model- or project-specific and provide a (unique) scope for the BPMN elements contained in a Definitions element.

2. Regarding IDs, we should also keep in mind that duplicate IDs might break resolution of references. We definitely should warn users in that case.

So, two things to be done here - in the future ;-)
a) validate models on save in our editor
b) prompt the user for a target namespace