Just a note, We shouldn't assume that all the queries that will be created would
be from the UI provided and avoid having this kind of validation.

Are you sure that this is very important issue with P2 priority ?
We have number of not implemented validation rules and this is just only one 
in this list. I don't see big importance of this issue.
I believe we have other high priority issues that should be done at first place.
We even don't have all static analysis rules implemented.

I would say this is important, since anyone who uses correlations will do use
the query. And inadvertently runs into this issue. It requires a good amount of
studying and understanding the correlations, BPEL spec and XML representation of
the data in terms of understand what went wrong with this query. My experience
has shown that relatively knowledgable developers ran into this pitfall of
making the mistake. 
I can say that this is more important and useful than some of the static
analysis,  lets say the validation doesn't point out that the operation selected
and the variable type didn't match up in receive. It will waste time, but the
developer will find it relatively easy to debug and fix it. Where as this query
of property alias is not that easy. He may have to debug the java code in which
the engine is written. 
This deserves the priority it is assigned.

Kiran,
could you please provide to me additional details on this.

I cannot understand the essence of this issue from your original description .

I just understand that there can be BPEL file ( that could be created not in our
IDE ) with incorrect property alias.
So we need to determine such incorrect property alias declarations.
I don't understand exactly wrong situation in this issue.

Could you please point to me incorrect example ( previously mentioned by you ) 
and pointer to incorrect place in this example.
And as opposite: correct example and difference between incorrect example.
This will help to me to write correct validation rule.

Thank you.

This is all WSDL. No BPEL file is involved here. Property aliases are in WSDL
file. What i am asking is to validate the query that is written for a property
alias.

1) WSDL message part can be defined as Element, in that case the query can be
written in one of the two styles. The two different ways the query can be
written in shown earlier in the description.

2) WSDL message part can be defined as type. In this case there is only one way
a query can be written. This is also described earlier in the bug description.

We need to make sure the wsdls(property aliases) that are written will be
conformant to these styles of query based on part's definition. We should point
out if the query  for type is written in a style that would match the element's
query style and vice versa. We should point out if the query's first node
doesn't match the correct node name. Correct node name would be inferred from
the schema definition of the part.

If you still have issue please call me.
626-471-6025

Kiran,
we are in different timezones. So I cannot call to you in time that is
appropriate for you and me.

It seems I'm absolutely stupid idiot, but I didn't find in your last 
description requested information :

>Could you please point to me incorrect example ( previously mentioned by you ) 
>and pointer to incorrect place in this example.
>And as opposite: correct example and difference between incorrect example.

Could you please write it one more time with some markers where is correct 
and where is incorrect examples ?

Please note that I'm not expert neither in BPEL nor in WSDL ( possibly 
you are ). But I'm responsible person for validation ( I don't know why ,
but it is true ). So I need to understand exactly algorithm that I 
should write for handle this situation.

From your description I cannot understand exactly what you suggest:
1) Handle ONLY situation when "type" or "element" attribute is used in message
definition and check that there is no leading "/Invoke1parentElement/".
2) Handle situation for checking query attribute with its correctness.
I mean here checking existence and conformance Xpath expression in query
to XSD defined element or type. 
This is two different cases.
The second case is like other existed issue in BPEL category about checking
any Xpath expressions to conformance to XSD.
And they should be done together.
This is high usability impact BUT it is not VERY important thing and we 
can postpone it to next release.

Created attachment 38262 [details]
validation explanantion

Added a document explaining, pls let me know if you have more questions

Thank you.
This is a good explanation.

But still I don't understand your concern here exactly.
Please look at this example:

    <bpws:propertyAlias propertyName="tns:property1"
                        messageType="tns:Invoke1parentMessage1"
                        part="Invoke1parentPart">
            <bpws:query>/Invoke1parentElement/string</bpws:query>
    </bpws:propertyAlias> 


Do you thing that examples below are incorrect FROM POINT OF VIEW this issue :
    <bpws:propertyAlias propertyName="tns:property1"
                        messageType="tns:Invoke1parentMessage1"
                        part="Invoke1parentPart">
            <bpws:query>/SomethingWrong/string</bpws:query>
    </bpws:propertyAlias> 

    <bpws:propertyAlias propertyName="tns:property1"
                        messageType="tns:Invoke1parentMessage1"
                        part="Invoke1parentPart">
            <bpws:query>/Invoke1parentElement/somethingWrong/bpws:query>
    </bpws:propertyAlias> 

They are obviously incorrect.
BUT I WANT TO UNDERSTAND EITHER WE NEED TO FIX IN THIS ISSUE correctness of
Xpath expression as a whole or we need concern about leading "/" only ?

Because there are already issues about XPath correctness ( this is other case 
but the same essence ): http://www.netbeans.org/issues/show_bug.cgi?id=84077,
http://www.netbeans.org/issues/show_bug.cgi?id=85437

Now this is only thing that I want to know.

Changed version to 5.5.1

The fix for this issue should be part of general changes in validation.
Probably it will not be fixed in Gavotte. Should discuss it with Kiran.

No objections in 48 hours. Waived.

sorry for the long time it took to get back. There are so many things at hand
and it slips through my mind every day. Even though i wanted to update this bug
ever since we missed the phone conversation, i finally remembered to do it today.

To answer your question, the issue i am pointing here is not the correction of
the xpath as a whole. I understand that is a bigger undertaking and is filed as
a different bug too. 
while correctness of '/' is part of the thing, the other part is the first step
in the xpath. Meaning, what i am asking here is the correctness of
'/<firstStepNode>' combination. 
I hope that it is not too late and the bug will be considered for kenai and not
waived.

Removed Beta EP551_WAIVER_APPROVED keyword - we are going forward to FCS.

New validation is added. 
It applies the described rule and also check the query XPath by steps. 
It also checks is there a difference between the type of query and the type of 
correlation propery.