Subject: Re: Ambiguity in BLOCK semantics

From: "Putzolu, David" <[email-masked]>
Date: Sun, 13 Feb 2005 18:49:33 -0800

> I think the main challenge is that the LFB may need to be more
> accomodating. We cant assume a certain "design". The 
> indirection example
> will make it really easy to parse for some FEs but not 
> others; i know of
> ASICs where that would be a real nice straight mapping (since they do
> have such indirections) and of others where this would a complete pain
> and would require the intervention of the CE to chew things  into
> something along the first example from David. Whats more 
> interesting is
> i have seen desire to have NH as a LFB on its own right where the NHID
> would infact be an alias; 

While I agree that we cannot assume that a FE be designed in
a certain way, I think we can assume that the FE software can
"cook" the ForCES protocol into whatever the representation is
that the FE hardware prefers.  Put another way, I doubt (at least
the a generation or two of) FE hardware will "natively" speak
ForCES in the asics.

Cheers,
David

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 13 Feb 2005 23:06:53 -0500

On Sun, 2005-02-13 at 21:49, Putzolu, David wrote:
> that the FE hardware prefers.  

Indeed, except the way you represent in the LFB will make some s/ware in
some FEs (and as a result associated CEs) work harder than others. 
The examples you provide are not very different from most ASICs layouts
out there do things. So pick any of your two examples at the cost of the
other.

> Put another way, I doubt (at least

I would be pleasantly suprised if they did.

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Mon, 14 Feb 2005 18:24:08 +0100

After discussing again with Jamal, I understood that his semantic of the 
BLOCK selector actually does not leave room for ambiguity, given that a 
simple (but not yet explicited) rule is used:

In the previous example of

 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

According to Jamal, this will always result in:

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

So I think the implict rule can be explicited as:

all pathdata(s) that follow the BLOCK selector apply (in turn) to all 
selections made by the BLOCK selector.
Exception: if the pathdata that follow are more than a single DATARAW, 
then each datapath maps to a selection (and they must be the same number 
of both).

This means for instance that:

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

will result in:
{...,(b,x,x,x),(b,x,x,x),...}

Given that this removes the ambiguity, I guess we could keep the BLOCK 
anyway ?
Regards,
-Robert

-- 
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: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Feb 2005 12:27:34 -0500

The ambiguity is that if those three SETs were three DATARAWs, then the 
first would apply to entry 4, the second to entry 5, and the third to entry 
6.  Thus, changing the TLV used to hold the follow on information will 
change the semantics?

(For an extreme case, suppose we had a PATH-DATA that meant "all".  We 
probably need this to allow someone to set an entire LFB anyway.  So now, 
if I use three DATARAWs it means one thing, and if I use three PATH-DATAs 
with path="all", it means something different?)

Yours,
Joel

At 12:24 PM 2/14/2005, Robert Haas wrote:
>>>>accomodating. We cant assume a certain "design". The indirection example
>>>>will make it really easy to parse for some FEs but not others; i know of
>>>>something along the first example from David. Whats more interesting is
>>some FEs (and as a result associated CEs) work harder than others. The 
>>examples you provide are not very different from most ASICs layouts

---

From: Robert Haas <[email-masked]>
Date: Mon, 14 Feb 2005 19:04:20 +0100

Joel M. Halpern wrote:

> The ambiguity is that if those three SETs were three DATARAWs, then 
> the first would apply to entry 4, the second to entry 5, and the third 
> to entry 6.  Thus, changing the TLV used to hold the follow on 
> information will change the semantics?

Right, this is what I captured in the rule. I agree it is not the 
cleanest design. It would be worthwhile to distinguish the BLOCK 
assignment (which is really what we are interested in here) vs the 
INDIVIDUAL assignment.

> probably need this to allow someone to set an entire LFB anyway.

Yes, a one-shot SET for all attributes of an LFB would be helpful, but 
not mandatory.

>   So now, if I use three DATARAWs it means one thing, and if I use 
> three PATH-DATAs with path="all", it means something different?)

An all-PATHDATA and a DATARAW should be considered equivalent (they set 
all the values in both cases), so it does not make sense to have a 
sequence of them overwrite eachother.

To be precise the rule would be:

all pathdata(s) that follow the BLOCK selector apply (in turn) to all 
selections made by the BLOCK selector.
Exception: if the pathdata that follow are more than a single DATARAW or 
a single all-PATHDATA, then each pathdata maps to a selection (and they 
must be the same number of both).

Regards,
-Robert

>> After discussing again with Jamal, I understood that his semantic of 
>> the BLOCK selector actually does not leave room for ambiguity, given 
>> that a simple (but not yet explicited) rule is used:
>>
>> Exception: if the pathdata that follow are more than a single 
>> DATARAW, then each datapath maps to a selection (and they must be the 
>> same number of both).
>>
>> Given that this removes the ambiguity, I guess we could keep the 
>> BLOCK anyway ?
>> Regards,
>> -Robert
>>
>> Jamal Hadi Salim wrote:
>>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 14 Feb 2005 14:28:21 -0500

> > three PATH-DATAs with path="all", it means something different?)

sigh. Note that Joel and I have very different views of what it means to
follow a selector. Otherwise there is no ambiguity  _at all_, i.e the
premise behind Joels arguement is innacurate in my view (as he does
think of mine) and i was hoping we would settle it at some point - but
if people want to talk about it now i am more than willing.

It actually has nothing to do with BLK like i said earlier but rather in
where you are in the hierachy; 
Take an example of a path we have to a table which has 100 entries (no
BLK flag set). 
Say you provide one dataraw with one row entry; What does that
semantically mean? To me it means you set those 100 rows to that
dataraw's value.
OTOH, if you have 100 row entries it means you sequentially set the
value to those entries in the order they are provided.
You have anything other than one or 100, its an error.
no BLKs were used, but same rule applies.

> sequence of them overwrite eachother.

In the example above, its like sending 100 row entries with 
_exactly_  the same values. While legit may not be a sensible thing to
do.

> must be the same number of both).

Like i was pointing in earlier email:
"You must find the path to the target first"; once you do, only then can
you use the supplied DATARAW and only then does it make sense to have a
DATARAW! (i.e classify then apply data). If the path leads to parallel
nodes in the hierachy, then all nodes have to have exactly that piece of
data applied to them. 

To use your example:

For table entries 4 5 6,

let me break it down in several ways "//" which will show all cases
as comments:
1) Applying data to a table
--> Path to table X, which has 100 entries
// We are now at the table X
// any data that follows here will have to apply
// to the whole table and so needs to pass the necessary error
// checks
----> dataraw = { one or 100 rows worth of data each with name, surname,
address, city}

2) Applying data to a select rows in a table
--> Path to table X, 
// We are now at the table X
----> select row entries 4 5 6,
// we have highlighted only rows 4, 5 and 6
// we can only have 1 or 3 rows worth of data
----> dataraw = { one or 3 rows worth of data each with name, surname,
address, city}

3) Applying data to a select rows and columns in a table (your example)
--> Path to table X, 
// We are now at the table X
----> select row entries 4 5 6,
// we have highlighted only rows 4, 5 and 6
----> select column name
--------> data = { a } 
// given the path so far: we have tableX, row 4,5,6 and column "name"
// clearly, unambigoulsy it means just that: i.e this data belongs
// to tableX, rows 4, 5,6 column name. The error check needed
// is to make sure that its of the correct length
    
----> select surname 
--------> data = { b }
----> select address 
--------> data = {c}

--------------

Where is the ambiguity?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 14 Feb 2005 14:34:26 -0500

The arrows were a little misleading so didnt show the nesting properly
for #3; it should be; comments are the same as before:

--> Path to table X, 
----> select row entries 4 5 6,
--------> select column name
--------> dataraw = { a } 
--------> select surname 
--------> dataraw = { b }
--------> select address 
--------> dataraw = {c}

---

From: Weiming Wang <[email-masked]>
Date: Tue, 15 Feb 2005 12:16:43 +0800

Hi all,

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
Subject: Re: Ambiguity in BLOCK semantics

> no BLKs were used, but same rule applies.

I agree with Jamal's that the confusion that leads to the ambiguity debate is
only about what a single row entry in dataraw really means, which means to apply
to all rows selected or only to the first row? By explicitly describing this in
our draft, we'll then kill the ambiguity, I think. I agree well that we define
the meaning as applying to all rows selected. I also agree the one-or-all
semantics, i.e., all partially encoded data other than one or all should be
interpreted as errors.

This question is purely an issue for data encoding grammar, and has nothing to
do with block actually.

Cheer,
Weiming

---

From: Weiming Wang <[email-masked]>
Date: Tue, 15 Feb 2005 13:17:32 +0800

Joel,

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: Ambiguity in BLOCK semantics

[Weiming] In this case, I think should we only allow one PATH-DATA with the
path='all'. If it has more than one PATH-DATA will 'all' path, it leads to an
error, for it's duplicating. If it has three PATH-DATAs with individually
path=index 4, index 5, and index 6,  there will be no ambiguity. But I personall
think the latter case should also be prohibited if the father PATH Selector has
already selected the index 4, 5, and 6, because it is also a duplicating and
will result in semantic confusion for nested PATH-DATA. I think in a tree
structure formed by nested PATHs, the subpath will always inherit its father
path rather than modify it so as to keep the whole path consistent.

Cheers,
Weiming