----- Original Message -----
Sent: Monday, September 20, 2004
1:17 PM
Subject: RE: One point to
clarify
Mike:
This
is precisely the issue:
<VerifyContent>/FilterResult/Message//ErrorList[count()=0]</VerifyContent>
will be true in
the two following cases:
(a)- there are messages selected by filter, but
none with an ErrorList.
(b)- there were no messages selected by filter,
because it timed-out.
Si I guess what we would write if we want the
expr to be true only in case of (a), is:
<VerifyContent>/FilterResult/Message[count()!=0]//ErrorList[count()=0]</VerifyContent>
Would that work?
[MIKE] - I think that your above query would
acutally do the opposite.. meaning it is counting the number of Messages
that DO NOT
have an ErrorList present [count()=0]. So it could
conceivably evaluate to "true" (pass), if if finds any message at all
that does not contain an ErrorList, which is not our intent if we want
to invoke the default behavior of the TestAssertion>
[Jacques
Durand] actually my query path didn't make sense...(the count()!=0
is superfluous) By the way, a "true" value here
means
that the XPath
returns a non-empty node-set as
result.
I should have written my XPath Filter
<VerifyContent>/FilterResult/Message[//eb:ErrrorList][count()=0]</VerifyContent>
[MIKE] - This query returns a boolean
"true/false" result . The boolean result is determined by
the "count()"
function.
This query counts the number Messages having an
"eb:ErrorList" present somewhere in the message ( I could have been more
specific where.. but
this
suffices for the explanation) . If the
count()=0, then the VerifyContent result is "true", and the
TestAssertion passes (default behavior).
Meaning..
if NO Messages containing an
ErrorList are found in the FilterResult.. then the TestAssertion
passes.
[Jacques
Durand] All this is based on this
interpretation:
- if this XPath has
produced a non-empty node-set, the assertion evaluates to
"true".
[MIKE2] - I believe that use of the
"count()=0" function does not produce a node-set object.. but produces a
"boolean" object result Not all XPath queries produce a
node-set. Some XPath expressions produce a number, or a string, or
a boolean objectas their result. I believe a non-empty string
results in a "true" result. A boolean object result of "true"
creates a final XPath query result of "true". A number
returns true if "it is neither a positive nor negative ZERO or a
NAN" . (Please see section 8.3.4.4.1 of the current Test Framework
document for a description of the different types of objects that can be
returned by an XPath query.) So... what this means for this
particular TestAssertion ( I think ) is that we are doing a boolean
evaluation count()=0 on the number of Message elements that contain an
ErrorList
- if this XPath has
produced an empty node-set, the assertion evaluates to
"false" .
[MIKE2] - I agree , if we are producing a
node-set object as the result object. But I believe we are
producing a boolean result object here (because of the predicate
count()=0 ) If the predicate were
simply count(), the result would be a number. If the predicate
were simply [//eb:ErrorList], the result would be a
node-set. So the semantic result of the query below would be a
boolean one, with a result of "true" (if count()=0) or "false" (if
count()!=0). And this would satisfy our TestAssertion without the
need for any additional semantic paramters (such as
empty="true").
So in the present case, at the time we evaluate
teh XPath, we want a positive outcome (true) if either (1) no messages
received, (2) messages received but with no ErrorList. But in case (2),
the above XPath would not produce any node set... which means
"false".
One simple way to deal with this corner
case (emptyness of filter result) is to write something like:
<VerifyContent empty="true">/FilterResult/Message[//eb:ErrrorList][count()=0]</VerifyContent>
what do you
think?
[MIKE2] - I think that we need to verify
the semantics of our expression before we determine if we need to
introduce more operators into an already complex
syntax.
Jacques
----- Original Message -----
Sent: Friday, September 17,
2004 10:03 PM
Subject: One point to
clarify
Mike:
One more point to clarify :
3) Do we need to define a "stepDurationFail" Test Driver
parameter ? Agree we don't BUT:
Now, shouldn't we have a more explicit way to test the emptiness
of a filter result (e.g. an explicit built-in
boolean function like "emptyResult") ? We should, because regular
TestAssertion conditions on the result messages
will not have an intuitive meaning. They usually assume that
there is at least one message in the result buffer.
If this result set is empty, teh testAssertion outcome is
unclear: e.g. verifying that no message filtered has
a particular header element: "NOT(//mymessage/myelement)" what if
the filter result is empty? is that a "true" or a "false"?
So it seems we need a primitive to test this. (Of course, we
could use "count()" to test the number of messages...
but for convenience shouldn't we
have something much shorter like above boolean built-in?)
[MIKE] - I think the easiest way to code this
is:
<GetMessage>
<Filter>/MessageStore/Message//ErrorList</Filter>
</GetMessage>
<TestAssertion description="Verify that no
ErrorList element is present">
<VerifyContent>/FilterResult/Message//ErrorList[count()=0]</VerifyContent>
</TestAssertion>
Using your StepDurationFail
parameter:
<GetMessage>
<Filter>/MessageStore/Message//ErrorList</Filter>
</GetMessage>
<TestAssertion description="Verify that no
ErrorList element is present using the StepDurationFail
parameter">
<VerifyParameter>
<Name>StepDurationFail</Name>
<Value>true</Value>
</VerifyParameter>
</TestAssertion>
I'll put it in the spec for with documentatio
for the <Filter> element.
Also, could you post the OpenOffice draft on our site? (Or
its PDF conversion?
it is very easy to export a PDF from OpenOffice
)
[MIKE] - I just
posted it ( tracking is turned on). I added the 3 use cases,
plus their normative representations in the
Appendix.
Also, many small
changes as we implemented here. I'll post my
response to the ETSI comments shortly.
Thanks,
Jacques