Validate the queries that are defined on the property alias.
When the part is defined of an element, there are two variations of the query.
There is only one variant possible. Please look at the following.
Also related bug http://www.netbeans.org/issues/show_bug.cgi?id=83335.
part as element,
and part as type,
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.
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.
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
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.
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]
Added a document explaining, pls let me know if you have more questions
This is a good explanation.
But still I don't understand your concern here exactly.
Please look at this example:
Do you thing that examples below are incorrect FROM POINT OF VIEW this issue :
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,
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
I hope that it is not too late and the bug will be considered for kenai and not
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