Subject: RE: Adding structures and lists to OCP

From: "Martin Stecher" <[email-masked]>
Date: Fri, 23 May 2003 14:25:51 +0200

Alex,

I agree to most what you wrote and explained.

Structures and lists are useful elements and marking them with (curly) brackets helps to scan and parse them easily. 

The motivation to add nesting is also reasonable to me but I would like to restrict it to a smaller minimum than you do.

The deeper nesting example (3b) is already very complex (I always had problems with programming in LISP)

As long as we do not have good examples why we need nesting deeper than level 1, I would like to restrict it to that.

So only allowing a value to be

  an atom
  a list/structure of atoms
  a list/structure of lists/structures of atoms

By the way: What is the current status of atoms? Strings, integers and floats?

Regards
Martin

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 23 May 2003 09:03:27 -0600 (MDT)

On Fri, 23 May 2003, Martin Stecher wrote:

> I agree to most what you wrote and explained. Structures and lists
> are useful elements and marking them with (curly) brackets helps to
> scan and parse them easily.

These syntax changes should appear in the next draft release then,
provided there are no further objections or improvements.

> The motivation to add nesting is also reasonable to me but I would
> like to restrict it to a smaller minimum than you do. The deeper
> nesting example (3b) is already very complex (I always had problems
> with programming in LISP)
>
> As long as we do not have good examples why we need nesting deeper
> than level 1, I would like to restrict it to that.
>

Agreed.

> By the way: What is the current status of atoms? Strings, integers

Actually, there are no well-defined "types" for atoms yet, only syntax
rules and some comments accompanying parameter definitions. As of now,
one can parse OCP messages but cannot check for parameter validity
beyond a few known restrictions. This will change.

I suspect the following atomic types will be needed to accommodate
current OCP needs:

	uri
	numeric identifier
	size
	probability
	TBD

The last one, "TBD" (to-be-defined) can be used to describe parameters
that will be determined by other specs. For example, a security
negotiation profile may have some custom parameter types that we
cannot predict and that do not fit any known OCP types.

Note that I do not see much benefit of defining "generic" types such
as "string", "integer", or "float" because we are not documenting a
general purpose programming language. OCP applications will have
specific uses for "integer-looking" parameters and are unlikely to
benefit from being able to, say, perform arithmetic operations on two
fields without knowing that field true meaning. In other words, if a
parameter is useful for you, you should know its exact type. Note that
it is still possible to _parse_ any parameter, whether you know its
type or not.

Thank you,

Alex.