OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [regrep] Re: [Meeting Minutes] RS Spec review special meeting1/25/2005


Farrukh Najmi wrote:
> Diego Ballve wrote:
> 
>> Farrukh Najmi wrote:
>>
>>> Farrukh Najmi wrote:
>>>
>>>> Diego Ballve wrote:
>>>>
>>>>> Farrukh Najmi wrote:
>>>>> ...
>>>>>
>>>>>> * Diego: 9.2.2.2. Iterative federated query behavior not clear
>>>>>>  o Resolution: Agreed that intended behavior works fine. Diego
>>>>>>    to suggest revised text for Iterative federated query behavior
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ...
>>>>>
>>>>>
>>>>> Changes are limited to the last paragraph:
>>>>>
>>>>> Current:
>>>>>
>>>>> "When a client submits a federated iterative query, the registry 
>>>>> MUST use the startIndex attribute value of the original request as 
>>>>> the startIndex attribute value of the routed request sent to each 
>>>>> federation member. In such cases the registry MUST return a 
>>>>> totalResultCount attribute value on the federated query response to 
>>>>> be equal to the maximum totalResultCount attribute value returned 
>>>>> by a routed query response from each federation member."
>>>>>
>>>>> Suggested:
>>>>>
>>>>> "When a client submits a federated iterative query, the registry 
>>>>> MUST use the startIndex attribute value of the original request as 
>>>>> the startIndex attribute value of the routed request sent to each 
>>>>> federation member. The response to the original request MUST be the 
>>>>> union  of the results from each routed query. In such cases the 
>>>>> registry MUST return a totalResultCount attribute value on the 
>>>>> federated query response to be equal to the sum of totalResultCount 
>>>>> attribute values returned by each federation member."
>>>>>
>>>>> Regards,
>>>>> Diego
>>>>>
>>>> +1. Fixed for draft 02. Thanks Diego!
>>>>
>>> Oops I sent my +1 too soon before careful reading...
>>>
>>> In the single registry iterative query case, the totalResultCount on 
>>> an AdhocQueryResponse is not the total # of results returned but the 
>>> number of results matched within the registry.
>>>
>>> For this reason in the federated iterative query case the 
>>> totalResultCount MUST be the MAX not SUM of all individual 
>>> totalResultCounts.
>>>
>>> I would rephrase your paragraph to:
>>>
>>> "When a client submits a federated iterative query, the registry MUST 
>>> use the startIndex attribute value of the original request as the 
>>> startIndex attribute value of the routed request sent to each 
>>> federation member. The response to the original request MUST be the 
>>> union  of the results from each routed query. In such cases the 
>>> registry MUST return a totalResultCount attribute value on the 
>>> federated query response to be equal to the maximum of 
>>> totalResultCount attribute values returned by each federation member."
>>>
>>>
>>
>> Then I missed the point. You are saying that, for example:
>> We query Reg A, federated with Reg B and Reg C.
>> - Query matches 4 objects in Reg A
>> - Query matches 5 objects in Reg B
>> - Query matches 3 objects in Reg C, 2 of wich are replicas from A.
>>
>> totalResultCount = ?
>> I though MAX would return "5" in this case.
>> Plain SUM would be "12", but that is incorrect too.
>> Best answer would be "10"
>>
>> Diego
> 
> 
> The totalResultCount parameter would have been better called 
> totalMatchCount which is the number of objects matched in the target 
> registry.
> 
> The point of this parameter is to allow client to dtermine how many 
> times to iterate over the iterative query (while (i < totalResultCount))
> As long as totalResultCount indicates there is more data to fetch the 
> client does another query iteration after bumping up the startIndex.
> 
> So lets say the maxResults (how many most can be fetched in one 
> iteration) is 2 then this is how your example plays out (compare with 
> 6.2.1 in RS draft 01):
> 
> Iteration 1: startIndex=0, maxResults=2, totalResultCount=5, # of results=2
> Iteration 2: startIndex=2, maxResults=2, totalResultCount=5, # of results=2
> Iteration 3: startIndex=4, maxResults=1, totalResultCount=5, # of results=1
> 
> Hope that it makes sense why we need MAX instead of SUM. This is 
> definitely a little hard to explain but
> I hope I have it right.
> 

Thanks for the long explanation, but we are talking about the same thing 
in 1 point: for the client it is the max number of results.

What I meant by sum was SUM(MAX(Member1):MAX(MemberN)), from federation 
"router" point of view, not client, and in total, not per iteration. So 
in the end we would come to the same point.

Diego

-- 
Diego Ballve
Digital Artefacts Europe
http://www.digital-artefacts.fi



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]