Subject: RE: Packet Filtering (Re: Preliminary results from PCIMe technica l meeting, 1/24/01 - 1/26/01)

From: "Weiss, Walter" <[email-masked]>
Date: Wed, 14 Feb 2001 11:09:08 -0500

John,

I am confused by the following statements:

> What the real problem is that QPIM has 
> introduced several 
> notions that are completely lacking in QDDIM:
> 
>    - constraining the values of a variable or constant
Doesn't an information model explicitly constrain the allowable values of an
attribute?
>    - constraining the data types of a variable or constant
Can you explain what you mean here? Are you refering to the semantics of
variables within an expression? If so, isn't this more a function of the
language semantics for the expression of variables (ie. Perl notion of a
variable is somewhat different from C).
>    - binding a variable to a value
Isn't this also a language semantic? 

It seems to me that QDDIM fits rather nicely into an expression based
language. If we consider a QDDIM object as a structured data type, it maps
rather well. The ultimate question with respect to variables is where the
base variables are defined. Do we use QDDIM or a derivative or do we define
a whole new set of variables that duplicates all the semantics described in
QDDIM?

If we start from scratch, the most convenient approach is to create a list
of possible variables. However, as the list grows longer, organizing the
attributes is inevitable. A good parallel would be Fortran with flat
attributes, C with structures, and Java with classes. Since experience tells
us that structure is inevitable, we may as well define the structures now.
If we do, we have come full circle back to where QDDIM is now.

regards,

-Walter

---

From: John Strassner <[email-masked]>
Date: Thu, 15 Feb 2001 17:37:37 -0800

Hi Walter, please see inline.

regards,
John

At 11:09 AM 2/14/2001 -0500, Weiss, Walter wrote:

>Doesn't an information model explicitly constrain the allowable values of 
>an attribute?

<js>
No. What I'm talking about here is the ability to specify and model 
constraints. Saying that an attribute is a uint8 explicitly constrains the 
legal range of values that the attribute can take. What I'm looking at is 
in addition, constraining the allowable range of values that an attribute 
can have for a particular application (e.g., 0-63 instead of 0-127), 
attaching special semantics to certain values (as is commonly done in 
MIBs), and defining special relationships between a value of an attribute 
and something else. OCL would be the easiest (though possibly not the most 
efficient) way to do this with our model.
</js>

>variable is somewhat different from C).

<js> See above </js>

>Isn't this also a language semantic?

<js>
No. For example, in QPIM we may be dealing with an IPAddress, and want to 
restrict the values of said variable to just IPv4 addresses that are in 
CIDR format.
</js>

>base variables are defined. Do we use QDDIM or a derivative or do we 
>define a whole new set of variables that duplicates all the semantics 
>described in QDDIM?
>
>attributes, C with structures, and Java with classes. Since experience 
>tells us that structure is inevitable, we may as well define the 
>structures now. If we do, we have come full circle back to where QDDIM is now.

<js> Sorry, you lost me here. Can you please elaborate? </js>