← Prev in month ← Prev in thread

Re: One point to clarify

From
Michael Kass <>
Date
2004-09-24T15:19:01+00:00
ID
001b01c4a249$bd224ab0$
Thread
Re: One point to clarify
Jacques,

 

  I'm posting this to the list as you 
suggested.  My comments are [MIKE2]

 

Mike

 

  
----- Original Message ----- 

  
From: 
  Michael 
  Kass 

  
To: Jacques Durand 

  
Sent: Monday, September 20, 2004 4:57 
  PM

  
Subject: Re: One point to clarify

  

  
Jacques,

  
 

  
   More inline

  
    
----- Original Message ----- 

    
From: 
    Jacques 
    Durand 

    
To: 'Michael Kass' ; Jacques 
    Durand 

    
Sent: Monday, September 20, 2004 4:28 
    PM

    
Subject: RE: One point to clarify

    

    
inline

    
      
-----Original Message-----
From: Michael Kass 
      [mailto:]
Sent: Monday, September 20, 2004 
      10:51 AM
To: Jacques Durand
Subject: Re: One point to 
      clarify

      
 

      
        
----- Original Message ----- 

        
From: 
        Jacques Durand 

        
To: 'Michael Kass' ; Jacques Durand 

        
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-----
From: Michael Kass 
          [mailto:]
Sent: Monday, September 20, 
          2004 9:32 AM
To: Jacques Durand
Subject: Re: One 
          point to clarify

          
 

          
            
----- Original Message ----- 

            
From: 
            Jacques Durand 

            
To: '' 
            

            
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
← Prev in month ← Prev in thread