Re: [bpel-dev] BPEL xml source structure

[Wylie Garvin <Wylie_Garvin@xxxxxxxxxx>]

Michal and Kevin,

Regarding Michal's number (2) concern.
 The WSDL model handles that by maintaining a DOM tree in memory in
parallel with the EMF model objects.  Any modification to the EMF
model objects causes the DOM to be updated.  As a bonus, saving the
WSDL file is pretty easy (just write out the DOM tree), and for parts of
the model which were not edited, all the bits of the DOM such as whitespace
and comments are preserved.

We've talked about adding the same support
to the BPEL model, although it is a lot of work.  It might be something
to defer until after the version 1 timeframe.

Cheers,
Wylie

Kevin McGuire/Ottawa/IBM@IBMCA
Sent by: bpel-dev-bounces@xxxxxxxxxxx

03/13/2006 04:56 PM

Please respond to
"BPEL Designer project developer discussions."

To	"BPEL Designer project developer discussions." <bpel-dev@xxxxxxxxxxx>
cc
Subject	Re: [bpel-dev] BPEL xml source structure

Hi Michal, 

It is perhaps a result of your recent flu battle etc., that you view these
issues as medical concerns. 

Re: 1) 
My assumption is that we will be able to on-the-fly read in a older version
BPEL files.  We have our own custom EMF deserializer which gives us
a place to handle such things.  The in-memory model will however be
a 2.0 based one, so any saves would be 2.0 based saves.  As it works
with MS Word etc. 

Re: 2) 
Yeah, that's a tough one.  Its the plague of highly graphical editors.

The only solution I can see is that we keep better track of which parts
of the BPEL model have actually changed and surgically write just those
changes out.  The goal would be that a minor edit change would only
result in a minor file change.  This could be a challenge to implement.

We might at least be able to keep better track of the comments and keep
them with the element they were intended to be associated with according
to some heuristic (e.g. assume comment is wart'ed to the element that follows).
 This would reduce the itch, though its not a cure.

I'd like to understand better though the use case for preservation of markup
structure.  We always view the files as just one up from a binary
encoding (ie. not to be hand-edited), but perhaps that's wrong.  I
know in our previous discussions you had spoken of XML source views for
the entire process or parts thereof, which we thought was cool, but weren't
sure why one cared about the source.  Perhaps myopic on our part?

Yours in health, 
Kevin

Michal Chmielewski <michal.chmielewski@xxxxxxxxxx>
Sent by: bpel-dev-bounces@xxxxxxxxxxx

03/13/2006 04:24 PM

Please respond to
"BPEL Designer project developer discussions."

To	bpel-dev@xxxxxxxxxxx
cc
Subject	[bpel-dev] BPEL xml source structure

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