Problem 2 has been described in a separate issue 90585.

We can achieve detection of old unsupported BPEL versions with meaningful
message by:

1. create umbrella Unsupported_Process component that will be returned by
createRootComponent based on non-supported QName of element 'process' (instead
of having the method return null).  This Unsupported_Process will have no children.

2. UI could check namespace of Process component to generate meaningful message.

Good suggestion Nam. You are suggesting this should will only requrie
modifications to the BPEL OM implementation? It will not require any
modifications to any upstream XAM API?

Please note that the same issues (and more )will apply to WSDL files. 
WSDL files may include 
BPEL 1.0 extensions (not supported by our IDE - but possibly valid)
BPEL 2.0 obsolete schema namespace (not supported by IDE , need to be upgraded)
BPEL 2.0 final schema (supported)

Also WSDL should be prepared for case where user tried to open a WSDL 2.0 document. 

Opening separate issue for WSDL UI.

I have created additional issue and assigned to wsdl tools - issue 90644
I don't think the two issues are dependent. They seem to be parallel, but we may
need to coordinate so that solutions are consistent.

Yes Mike.  The suggested solution would only require changes in Bpel OM and Bpel
editor code.

Denis, Vitaly. The potential fix of this issue has 2 parts.
One is related to changes in BPEL OM and the second one in UI.
Denis please look at Nam suggestion, evaluate it and fix if it's possible.
Reaasign this issue to Vitaly after your part is complete.

I don't like Nam's suggestion.
It can lead to unexpected impact in various part of code.
It seems root element reference is almost always cached right after appearing
first valid BPEL content. So in this case I will need to provide some hack 
for replacing old valid Process reference to new UnsupportedProcess instance.
And otherwise : after XML is broken I will need to replace root element from
old good state to new UnsupportedProcess .

It looks very risky to implement.

I prefer do not touch getRootComponent() method but add one more method.
This method will return some instance of marker interface like
UnsupportedProcess. Each time when BPEL OM has not well formed state this method
can be checked and any additional information can be retrieved from return 
value. Such approach will not produce any issues in existing code and 
I don't need to modify already implemented methods. I need to write only 
new code.

But there is problem : I cannot determine namespace for root element after
file is broken.
Please see two cases:
1) File is originally broken. In this case 
AbstractDocumentModel::getDocument().getDocumentElement().getNamespaceURI() 
return to me correct namespace value of root element .
In this case all is OK.
2) File was originally correct. Later we change namespace from correct value 
to incorrect. In this case there is no way for me to get new incorrect 
namespace!
Previous call 
AbstractDocumentModel::getDocument().getDocumentElement().getNamespaceURI() 
will return to me last correct namespace ( the BPEL 2.0 ns ).
getRootComponent() is this case doesn't return null. It return last valid
Process object. But its method
getPeer().getNamespaceURI() 
also return BPEL 2.0 namespace.

So we have an adequate problem with described case.

Question: is there any way to get current namespace via XAM/XDM methods ?
If no then I will need to implement custom XML parser for recognition this 
namespace without XAM/XDM.

I introduce new API  method and its draft implementation.
This impl has problems and they needs to be fixed later.
Currently chosen approach works only in the case when file has 
old namespace from very begging.

Please give my recommendation a try.  It is the least code change.

Even though I mention createRootComponent() there is no needs to change its
implementation if you implement it correctly (always set process component with
the one returned from the factory).

You only need to define interface UnsupportedProcess for which implementation
will extends ProcessImpl and override all domain interface methods to throw
UnsupportedOperationException or IllegalArgumentException.  The cached root in
the BpelModelImpl will get refreshed by XDM/XAM when user fixes the unsupported
namespace to the currently supported one.  Maybe UI can offer to fix to
supported namespace automatically.

UI client code when calling BpelModel.getProcess() will get one instance of this
UnsupportedProcess and still get the underlying namespace through
UnsupportedProcess.getPeer().getNamespaceURL() to display in error details.

To answer Denis last question:

If sync throw IOException because of component factory return null for the
'process' element with unrecognized/unsupported NS then in case of initial
load/sync you probably can get XDMModel current Document.  However if that
happen during subsequent sync, XDMModel current document is still the original
document before sync.

Clarification: 
my suggestion is not about createRootComponent code change.  Its about having
the BPEL component factory return UnsupportedProcess object and still conform to
the general framework.  This will be more in line with XAM general multiple
version support strategy.

IMO, creating this additional API method on BpelModel is unecessary and might be
confusing.  Client code only need to know BpelModel.getProcess() which will
return UnsupportedProcess and allow client code to detect bpel version (from
underlying namespace).

Thanks Nam,
I understand your proposition and it could be a good enough.
But returning not null Component in createRootComponent() ( and as
consequence getRootCompoenent() ) lead to VALID state for BpelModel 
in the case when namespace is not BPEL 2.0 namespace.

I have tried your suggestion and discover that UI doesn't recognize 
not valid BPEL 2.0 document. This is the consequence of my letter description
about State. In this case OM doesn't notify clients about changing state
and they know nothing about appeared changes.
Of course we can notify clients somehow but this will lead to discovering 
all places where we need introduce this change . All this is too risky.
I don't like it.
This proposition lead to break old contract that exists between OM and clients
and this is bad.

I found decision how I can get current namespace and I use it.
I still want to use new API method and all works fine with my approach.

Vitaly, please use new API in BpelModel :
AnotherVersionBpelProcess getAnotherVersionProcess();

when model becomes not valid ( you know this from State change to not well
formed ) you can use method getAnotherVersionProcess() for checking it for 
not null. If so then you can ask namespaceURI and create corresponding message
error.

I will add also BPEL 1.1 namespace and BPEL 2.0 draft namespace constants 
into BpelEntity interface.

*** Issue 93743 has been marked as a duplicate of this issue. ***

UC. User Ctrl-C, Ctrl-V old bpel to sources. In this case we can detect that old
schema namespace URI is used and show message about this. Then user go to sources,  
corrupts bpel (e.g. removes </process>) and inputs correct schema namespace URI.
Then user switches to design view and see error message that schema namespace
URI still incorrect. In described usecase we can not update message, 
model will return obsolete information about error, user will try to fix
namespace URI again and again. 

So the fix updates only error message. Now error message attracts user attention
to possible reasons of problem and one of these reasons is Incorrect BPEL Schema
namespace URI.

Verified in build 070531.