Re: [bpel-dev] BPEL xml source structure

[Michal Chmielewski <michal.chmielewski@xxxxxxxxxx>]

Kevin McGuire wrote:

Hi Michal,

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

Perhaps indeed. I'll try to use another metaphor next time.

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.

You know Kevin, it's itching a little less now ...

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

True. But doable.

In the approach we (Oracle)  had taken we had facaded the model behind the XML dom. So any updates to the model are reflected in the DOM via DOM API manipulations. At the end, it's just document.toXML() and we are done. Would not this be the simplest way ?

Now I know the EMF internals might prevent this, but it seems rather strange that this be not an option in EMF. Since we are basically reading XML documents that have ecore models, could we ask the good EMF people for this lovely feature ?  I mean that sort lies in their domain ....

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.

Yeah, tricky and probably would fail. That would be like Chinese water tortures for someone that wanted the tool to respect the XML source.

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?

Perhaps. All the lovely eclipse structured editors do have a degree of bi-directionality to them. The XML, XSD, WSDL, Java, etc - to a greater or lesser degree of course. I think we ought to march in that direction as well or at least plan how we could get there. Don't you think ?

Yours in health,

Thank you.

May your Achilles never fail you.

Kevin

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

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