Subject: Ambiguity in BLOCK semantics

From: Robert Haas <[email-masked]>
Date: Fri, 11 Feb 2005 18:38:42 +0100

To summarize the ambiguity with the use of a BLOCK construct, here is an 
illustration that should help:

With only DATARAWs following the BLOCK construct, no ambiguity :

  For table entries 4 5 6, (BLOCK construct selection)
  (each table entry has fields name, surname, address)
    set entry with (a,b,c)
    set entry with (d,e,f)
    set entry with (g,h,i)

necessarily results in:

{...,(a,b,c),(d,e,f),(g,h,i),...}

As a potential optimization, if all table entries are set with the same 
value (a,b,c), then instead of writing:
 
  For table entries 4 5 6,
  (each table entry has fields name, surname, address)
    set entry with (a,b,c)
    set entry with (a,b,c)
    set entry with (a,b,c)

one could also write:

  For table entries 4 5 6,
  (each table entry has fields name, surname, address)
    set entry with (a,b,c)

Now, if instead of DATARAWs, the BLOCK construct is followed by 
PATHDATAs, then there is an ambiguity:

  For table entries 4 5 6,
  (each table entry has fields name, surname, address, city)
    set  name with a
    set surname with b
    set address with c

 Does this result in (x means values that remain untouched):

 1) according to the semantics of example 4: 
   {...,(a,x,x,x),(x,b,x,x),(x,x,c,x),...} 

 2) or according to the semantics of example 15: 
   {...,(a,b,c,x),(a,b,c,x),(a,b,c,x),...}

That is the ambiguity.
-- 
Dr. Robert R. Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 11 Feb 2005 16:08:48 -0500

> {...,(a,b,c),(d,e,f),(g,h,i),...}

The semantics are pretty simple.

1) "Find the target first" - this is like a classifier filter "match"
and is provided by the path + selector
2) Once you find the target, apply the SET data (this is like the filter
action)

In your case above zone on table:rows 4,5,6; apply the data in order.

>   (each table entry has fields name, surname, address)

This is also legit, but not efficient, given the commonality of the
data set.

>   (each table entry has fields name, surname, address)

This fixes the efficiency issue above.

Essentially the rules for applying data are (This has absolutely nothing
to do with BLK rather with the BNF, but using BLK to make a point) 
[n is 3 in above case]:
Suppose that a block info TLV has highlighted "n" indices.  In that
case, a data TLV below that block info TLV may contain data for either 1
or n entries.  Any other number of data entries is invalid.
In other words:
(a) If the TLV contains data for 1 entry, the implication is: "Apply
this data to each of the n indices."
(b) If the TLV contains data for n entries, the implication is: "Apply
each piece of data, in sequence, to the n selected indices.  I.e., apply
the first piece of data to the first index, the second piece of data to
the second index, etc."
c) error

(a) is an efficiency subset for b) - you can get rid of it although i
dont see why you wouldnt want to.

>   (each table entry has fields name, surname, address, city)

Ok, in this case the path classifer says match on rows 4, 5, 6 cells
name, surname, address.
Clearly paths could be hierachical and the hierachy is definable by
nesting TLVs....
The data target is the cells. 

>    {...,(a,b,c,x),(a,b,c,x),(a,b,c,x),...}

I dont see it. You must classify the path first. Then you decide what
data to apply.

So lets repeat example 4 and 15 keeping in mind "classify path first
then set the data" (Should be noted the idea of classifying then
applying the data is defined with the BNF and has nothing to do with
BLK):

First Classify:
- In example 4, the Path-data TLV specifies table2 (ID 4), then
highlights a range of indices (0-5). So you have classified to those 6
rows. 
- In example 15, the first Path-data TLV specifies table4 (ID 6), then
highlights a list of indices (let's modify the example to choose indices
5, 7, and 9).
Classification selects table 6 then rows 5, 7 and 9 then each of 
the 3 different cells.

Apply data to the target:

Consider the two rules a) and b) I expressed above.  

I) In example 4: There is one Dataraw TLV after the block info TLV.The
classification result has 6 targets (rows). That TLV contains 6 pieces
of data.  The data info TLV had selected 6 indices, so rule (b) applies.
If i had 6 separate DATARAW TLVs then same rule would have applied. If i
have one piece of DATARAW - it would have applied to all 6 (as per rule
a)).

II) Example 15: The classification rule says we have 3 path targets.
There are three Dataraw TLVs after the block info TLV.  In this
scenario, apply the rules to each TLV independently.  The first TLV
contains one piece of data, therefore rule (a) applies, and the data
value 100 is written to each of the 3 chosen rows.  Each of the other
two TLVs also contains one piece of data, therefore rule (a) applies
again.

Note although i specified this with BLK, the rules apply to KEY as well
as simple indices.

cheers,
jamal