Subject: Re: Extension path and fuzzy sets

From: Graham Klyne <[email-masked]>
Date: Fri, 06 Nov 1998 12:43:50 +0000

At 09:00 31/10/98 -0500, Al Gilman wrote:
[...]
>The model I am working from is a "two-point boundary value
>problem" analogy.  One fixed boundary point is the notion of
>resource entities, the other fixed boundary point is the notion
>of a choice [of a course of action].

This is an interesting characterization.  One which I think is borne out in
the fax work, where I observe that comfort levels with the capability
description framework seem to rise as concrete examples are presented and
developed (see <draft-ietf-fax-feature-schema-xx.txt> for some examples
being developed).

>  There are two fundamental
>activities in the overall process: characterizing the resource
>entities by associating properties with them, and making choices
>by operating on the asserted properties of the visible resources.

Yes, but...  the -syntax- work is attempting to address the first activity,
and *part* of the second -- selection of acceptable choices from the
totality of possible choices.  The issue of of refining this to make a
single choice is, I am advised, sufficiently difficult/controversial to be
avoided at this stage.  Thus, your (simple) endpoint is not reched.

>What is growing is the richness of vocabulary used in the middle
>of this process.  The start point: a resource is an entity, and
>the end point: a resolution is a choice, are not changing.

I observe that in order to traverse the gap between "characterization or
resource" and "choice", one has to navigate the intervening terrain.  I am
trying to show how this can be done in a way which is consistent with
expected properties of the characterization.

>[...]  But
>as we add primitives and structures to how we characterize the
>entities, we should also allow for the addition of functions that
>can be used as we extract choices from complex characterizations.
>It _can_ all be done in Boolean forms, but we are at risk of
>requiring very _compound_ assertions in the meta-dialog if we
>don't allow the use of _complex_ operators in the statement of
>policies.

Hmmm... what kind of complex operators do you have in mind?

>One source of simplicity is the entity/attribute calculus by
>which we build from the initial point.  Another source of
>simplicity is the functional decomposition calculus by which we
>refine the endgame.  We should be employing both of these
>simplifying resources to contain that demon complexity.

Is this substantially different from the approach being taken?

And a final observation:  I think the comments about complexity may have
more to do with abstraction.  The framework is based on a small-ish number
of simple ideas, and I have tried to keep it that way.  I think that it is
the abstract nature of the approach (brought about by a desire to deal with
different application/protocol environments) that may make some aspects not
immediately obvious.  My perception is that this is less of an issue when
concrete examples ae examined.  I am planning work on some materials to
present the framework *as applied to fax* in a way that will be more
intuitive to a fax engineer.  This could be applied to other applications.

#g

------------
Graham Klyne
([email-masked])

---

From: Al Gilman <[email-masked]>
Date: Fri, 6 Nov 1998 09:10:09 -0500 (EST)

I think that we are on a path to a position that would remove all
objection:

1. Don't say "don't give q-vaules any other semantics."

2. Terse citations of applications which use some semantics
beyond the order properties affirmed in the current document.

Details/explanation:

> avoided at this stage.  Thus, your (simple) endpoint is not reched.

[Aside: The -syntax- work should be taking functionality defined
in the absense of syntax and making it easy to express and parse.
But you are doing that.  Syntax, unfortunately, has at times been
used to cover a multitude of sins and to hide differences in
functional role that sometimes should have been better
distinguished.]

I would restate the second point as "There is no clear candidate
of a method for the last step which is uniformly superior across
all protocols and application contexts.  This part of the
processing is not standardized here and may be defined on a
protocol or service basis."

Existing practices include having protocols define a default
selection such as the textually first or last, or present the
options to the user (as in download site selection from a chain
of distribution points).

> expected properties of the characterization.

I didn't get my image across.  Think of an accordion and a string
hammock.  The end points are not a fixed distance apart.  In the
initial go the property space and the decision rules defined over
the property space are simple.  Then over time the property-assertion
and property-projection processes elaborate and the total value-flow
network grows in the middle.  In any application there is a complete,
connected graph.  Some of the pieces are not standardized.  By
extending the property values and operations, applications get a
richer and richer pallette in which to build the decision making
process.

> Hmmm... what kind of complex operators do you have in mind?

Well, the simplest is the historical one of a q-value formula
equal to the sum of products of property values from one side and
weight values from the other.  At each position in the sum, the
value or weight may come from either end of the dialog.

The other obvious one is to have resource property
characterizations which share a common list of characteristics
and characteristic-by-characteristic ranges of options for the
value of each characteristic, rather than spelling out all
combinations in a disjunctive normal form.

The catalog order form, in short.

Consider the application for a Virginia vanity license: you must
submit a list of three acceptable choices and accept the first
one that can be issued without resulting in duplication.  With
computer processing, there could be a separate option to request
only one but pay a small fee if the request failed because of
duplication.  This kind of protocol-flattened-to-policy is not
out of the question.  I guess this also is a matter of the
entification of an ambiguity group.  It is a choice between
choice lists.

I think that the major area of growth is in multistage
negotiation protocols.  As the networks and processors get faster
and faster, the importance of resolving the choice in one pass
diminishes.

> Is this substantially different from the approach being taken?

It depends on how much weight on gives to the logical,
extension-supporting side of the initial definition.  If you mean
only "is it concretely very different" I would give a clear "no."
But I view setting the logical backbone up to support continuity
through extension of concretes as a matter of great substance
because it affects the useful life of the institution of the
registry.

We should define how new property registrations relate to old
ones [non-duplication of tag token] and also how new property
operations relate to old ones [methods that apply to new classes
defined by the assertion of forms which return values in the
established classes].

> intuitive to a fax engineer.  This could be applied to other applications.

There are at least two abstractions that it is very risky to rule
out.  These are sets and price functions.

Simplicity is in the eye of the beholder.  You need both the
short list of rules and the short list of examples or someone or
other will conclude you don't know what you are doing.  Go for it!

Al