-
1. Re: comments on initial xsd jpdl 4
we discussed exactly the topic element vs attribute a full hour yesterday. and we swinged back and forth between element and attribute.
we looked into various bpmn modellers to see what kind of information they had apart from the
* diagram size
* activity box bounds coordinates, width and height
* transition/flow anchor points and bendpoints
it turned out to be only color and font in activities. therefor we think it should not be made extensible. and we thought about what the scope was of our graphical designer efforts.
g is only for the gpd. other extensions should go into their own extension element / attribute.
maybe we should even not put the g declaration in the xsd and cause every element should have an anyAttribute declaration for extensibility.
does this reasoning make sense to you as well ? -
2. Re: comments on initial xsd jpdl 4
Yes, a general extension mechanism should be put in place that allows the GPD and other consumers of the jPDL to extend the definition in an appropriate way.
GPD concerns should not leak into the jPDL XSD -
3. Re: comments on initial xsd jpdl 4
"tom.baeyens@jboss.com" wrote:
we discussed exactly the topic element vs attribute a full hour yesterday. and we swinged back and forth between element and attribute.
we looked into various bpmn modellers to see what kind of information they had apart from the
* diagram size
* activity box bounds coordinates, width and height
* transition/flow anchor points and bendpoints
Where is this info going then?"tom.baeyens@jboss.com" wrote:
does this reasoning make sense to you as well ?
No, since it does not say where the other info is going.... -
4. Re: comments on initial xsd jpdl 4
"thomas.diesler@jboss.com" wrote:
Yes, a general extension mechanism should be put in place that allows the GPD and other consumers of the jPDL to extend the definition in an appropriate way.
GPD concerns should not leak into the jPDL XSD
Funny, this latter remark is a 180 degree turn from what was initially the idea. Making one jpdl file with process and graphical info in it instead of having to keep two files in sync. The 'general extension machanism' is using good extensionpoints in the xsd. -
5. Re: comments on initial xsd jpdl 4
"kukeltje" wrote:
"tom.baeyens@jboss.com" wrote:
we discussed exactly the topic element vs attribute a full hour yesterday. and we swinged back and forth between element and attribute.
we looked into various bpmn modellers to see what kind of information they had apart from the
* diagram size
* activity box bounds coordinates, width and height
* transition/flow anchor points and bendpoints
Where is this info going then?"tom.baeyens@jboss.com" wrote:
does this reasoning make sense to you as well ?
No, since it does not say where the other info is going....
The only other info that we consider inside the scope of what we target might be color (although definitely not in the first releases). And we concluded that can always be encoded within the text field as only the designer has to manage it. -
6. Re: comments on initial xsd jpdl 4
"kukeltje" wrote:
"thomas.diesler@jboss.com" wrote:
Yes, a general extension mechanism should be put in place that allows the GPD and other consumers of the jPDL to extend the definition in an appropriate way.
GPD concerns should not leak into the jPDL XSD
Funny, this latter remark is a 180 degree turn from what was initially the idea. Making one jpdl file with process and graphical info in it instead of having to keep two files in sync. The 'general extension machanism' is using good extensionpoints in the xsd.
i wouldn't consider this a 180 degrees turn :-)
but if i understand you correct, you do have a point: we could as well leave the 'g' attributes out of the specified schema and leave it up the the designer to add this as one of the anyAttributes.
that is something we did not consider yet. and at first thought it makes sense to me as then the g attribute won't be offered in code completions to developers writing xml by hand.
what do you think of that, Koen ? -
7. Re: comments on initial xsd jpdl 4
If you take jBPM 3 'as is' it isn't :-)
i wouldn't consider this a 180 degrees turn :-)
The only other info that we consider inside the scope of what we target might
This is where we might see things differently, or to be more precise, I do not see anything at all :-)
The other info I was talking about was location, size etc... where does that 'designer' info go to?
Regarding the extension mechanism, you propbably misunderstood me. I do not think 'g' should be left out in the xsd. Au contraire... it should be more specific (you know, namespaces ;-)) -
8. Re: comments on initial xsd jpdl 4
we store all coordinates or bendpoints in attribute g. but i don't know what you mean with location and size.
as it is now g is the jpdl namespace. -
9. Re: comments on initial xsd jpdl 4
"kukeltje" wrote:
you know, namespaces ;-))
You don't want Tom to get the hives - you know about his allergy to namespaces ;-)
Seriously - as I see it, this is a clear case for using a namespace. I think there's a good chance another editor might come along, with a different persistent dataset to merge in.
-Ed -
-
11. Re: comments on initial xsd jpdl 4
fyi, i don't have an allergy to namespaces.
i want both to be possible: specify a namespace and then the process gets validated. or don't specify a namespace and your process will not get validated.
@Koen: i want only 1 namespace for jpdl and 1 for the configuration file. i don't want process files with multiple prefixes.
If you set the default namespace to jpdl, no element or attribute defined by us should have a prefix. -
12. Re: comments on initial xsd jpdl 4
@Koen,
Yes, or better, if g only will contain 'color' than not why name it color?
@Ed, you see... just like with real allergies... give the person little bits of the allergent (?) a large number of times, spread over time and the allergy automagically disappers.... They even think they were never allergic to it at all... LOL....
@Tom: Yes, the deafult namespace used should be jpdl which will not require prefixes then... -
13. Re: comments on initial xsd jpdl 4
what is the advantage of being able to deploy a potentially invalid (i.e. not validated) process definition?
-
14. Re: comments on initial xsd jpdl 4
Sorry.. Yes, I forgot to comment on that as well... Currently the reason is kind of not neat. The xsd was not always in line with the parser, so if you wanted certain functionality, you could remove the namespace declaration from the processdefinition and xsd validating was turned off. Imo, this should not happen in jBPM 4 (nor should it have been in 3, just a lack of time to keep all in sync, including docs)
So personally, I'd opt for not accepting a processdefinition if there is no namespace declaration, OR assume the latest and still validate.
