Re: Senarios for feature matching

[Graham Klyne <GK@xxxxxxx>]

At 22:44 07/04/98 -0400, Al Gilman wrote:
>to follow up on what Graham Klyne said:
>
>> At 16:32 06/04/98 -0700, Ted Hardie wrote:
>> >Graham,
>> >	Thanks for your notes on these issues; I have
>> >made some comments within the text excerpted below.  My
>> >general comment, though, is that we may wish to focus on
>> >the type declarations for registration.  If we do that right,
>> >one of the advantages to going through the registration
>> >process will be that the types will be well-known to potential
>> >users of the feature.
>> 
>> If I understand you correctly, this corresponds to my "closed protocol"
>> case:  the negotiating protocol knows in advance of all the features it is
>> likely to encounter.
>
>[Al, here...]
>
>I don't follow this deduction.  Is that what you meant, Ted?  Or
>did you mean that each registration contains a type definition, and
>we need to work on what is in a type definition in a registration?
>
>In that case, the negotiating protocol can know all possible feature
>values only if it walks the entire registry.  It can do that before
>it completes a negotiation, but not before it, say, is compiled.

I am trying to draw a distinction between feature types which are known and
understood before a program is compiled (these are easy to handle) and
those whose operations must somehow be dynamically interpreted by the
program using some form of external type definition (which I think is more
difficult).

>> But what about (say) a Web client/server:  these are components of a very
>> general resource-fetching application, and place no constraints on the type
>> of resource that may be fetched (and hence the kinds of negotiable feature
>> that might be encountered).
>
>Yes, but only traits of the web object that are describable via
>registered characteristic definitions can be used in negotiation.
>You aren't interested in all traits of the web objects in a
>choice set, only enough characteristics to resolve which choice
>to make.  That is a much smaller space.

In my view, the choice might still reasonably involve testing of types
which were not known when the program was compiled.  The issue here is not
thje size of the type space, but whether or not it is extensible -- i.e.
full knowledge of the types is built into the program.

>> Or in a more restricted case, consider negotiation of additions in HTCPCP
>> [RFC2324], where the additions are ranked by the order in which they should
>> optimally be introduced into the cofee.  RFC2324 defines:
>> 
>>         addition-type   = ( "*"
>>                           | milk-type
>>                           | syrup-type
>>                           | sweetener-type
>>                           | spice-type
>>                           | alcohol-type
>>                           ) *( ";" parameter )
>> 
>> These might correspond to an addition feature with values:
>> 
>>     sweetener < syrup < alcohol < milk < spice
>> 
>> Suppose I wish to introduce a new addition-type, whipped-cream, which is
>> added after milk but before spice.  How is this new relationship to be
>> defined to an HTCPCP processor which is already in use?  Must I return my
>> coffee-pot for an upgrade?
>
>If it implements the RFC, you can't.  If it implements the registry,
>you can simply register
>
>	sweetener < syrup < alcohol < milk < whipped-cream < spice
>
>as a type, identifying the homograph tokens with their correlates in
>the HTCPCP RFC, and you are done.  [Not that this teaches your Melitta
>to whip cream, but you get the point.  Your InstaPresso will give
>you any order including whipped cream.  Your legacy pot will implement
>all the cases it understands.]
>
>That is why, when you order your coffee with whipped cream, you had
>better list a fallback with milk...

That was maybe not an ideal example.  I agree with your response, but it
misses the point I am trying to raise, which is:  should we allow feature
type extensibility, or should we require feature registrations to relate to
predefined types?

Comparing tokens for equality can be handled within a predefined type
framework, but defining an ordered set of tokens requires a new type.

#g

------------
Graham Klyne