Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [bpel-dev] BPEL xml source structure

That's a very good point Thomas. I think with the notion of other elements being present in the BPEL source (such as documentation or any other meta data that may be burried there by other tools) this becomes a more important issue to address early.

-michal

Thomas Schulze wrote:
Hi Michal,

re. 2)

I think there are two issues, the one is the issue with the removed
comments, the other with the reformatting. I'm not sure if the reformatting
issue is that important that it needs to be addressed. It's done by almost
all graphical editors I know.

But the removal of the comments should be addressed, I think, because it's
a kind of loss of information. The BPEL standard introduces for commenting
purpose the <bpel:documentation> element which is allowed inside each other
BPEL element. Maybe the BPEL EMF model can put the comments found in a BPEL
like <!-- start activity --> into such a documentation element and it
shouldn't be lost any longer. This "transformation" maybe can be done as
one step of the tasks you've described in 1) ("migration on the fly").

Best regards/Mit freundlichen Grüßen,

       Thomas Schulze



Michal Chmielewski <michal.chmielews To ki@xxxxxxxxxx> bpel-dev@xxxxxxxxxxx Sent by: cc bpel-dev-bounces@ eclipse.org Subject [bpel-dev] BPEL xml source structure 13.03.2006 22:24 Please respond to "BPEL Designer project developer discussions."



Gents,

Couple of things are starting to itch me the wrong way.

1) I know one of the things we had talked about in the past is how we
would deal with pre 2.0 bpel sources. I think the way we left it is
pre-2.0 bpel sources
would undergo an 'import' process to be consumed by the designer. And I
think we said that we would only save 2.0 source.
I don't have fundamentally a problem with it. I would just like to make
sure that 1.x sources can be read *easily* (that is the import ought to
be transparent to the user). Much the same way a "Word 97" document can
be read but not written. Forcing the user to do a separate "import"
experience would be a (-1). I think the import wizard ought to exists,
just not be the only way to bring in a pre 2.0 bpel file into our world.

2) The XML bpel source file. I am not a big fan of destructive xml
source writes, ones where the source is (re)generated from the
underlying (in this case EMF) model. In trying to make the
sample/references run through the designer I had encountered that as an
issue. A heavily commented source file is re-generated on save with
everything being destroyed other then what looked the BPEL code (and
reformatted). This just itches me the wrong way. Like I said, it's just
an itch now, not a full blown open wound. It's not infected yet either.
Just an itch.

Best,

--
Michal Chmielewski, CMST, Oracle Corp,
W:650-506-5952 / M:408-209-9321

"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."

_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev


_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev


--
Michal Chmielewski, CMST, Oracle Corp, W:650-506-5952 / M:408-209-9321 "Manuals ?! What manuals ? Son, it's Unix, you just gotta know."


Back to the top