This diagram shows five BrowseNodes and their hierarchy. Node A might be, for example, Shoes. Node B might be Women. Node C, a child of BrowseNodes A and B, might be Women’s Shoes.
The number inside each node represents the number of items in the BrowseNode when
ItemSearch is called on Node A. BrowseNode C is a subset of
BrowseNode A and a subset of BrowseNode B. Perhaps fifty of the items in BrowseNode
C are also in BrowseNode A. When ItemSearch was run on
BrowseNode A, the operation returned that BrowseNode A has 200 items. When ItemSearch is repeated using a BinParameter Name value that was
returned in the first ItemSearch request, it is the same as
running ItemSearch on a child of BrowseNode A, which, in this
case, is BrowseNode C. By narrowing the search to only those values found in
BrowseNode C, ItemSearch returns only those items in BrowseNode
A that are also in BrowseNode C. As shown in the following figure, the number of
common items is 35.
As a result, ItemSearch returns that BrowseNode A now only
contains 35 items. While the change in the item count in BrowseNode A might, at
first, be confusing, understanding that ItemSearch is returning
only the intersection of BrowseNodes A and C explains why the number of items in
BrowseNode A changes. Notice that the item counts in other BrowseNodes can also
change.
Because the number of items in surrounding BrowseNodes can change with each new
drill down using ItemSearch, the BrowseNodes that contain the
greatest number of items can change dramatically. In the previous discussion, for
example, the number of items in BrowseNode A changed from 200 to 35 on successive
ItemSearch requests. Because ItemSearch returns only the top ten BrowseNodes that contain the
most items, the identity of the top ten BrowseNodes can change with each ItemSearch.