Re: hashed feature sets, representation and resolution

At 12:59 02/02/99 -0800, Ted Hardie wrote:
[...]
>> >I think this is workable, but we will need to be very careful in
presenting
>> >this to ensure that there is no confusion between g.<URI> h.<URI>;
>> 
>> After debating with myself whether this really matters, I agree.
>
>Great.  I think there is a large chance naive users will confuse the
>URI at which a feature is described and the URI at which a list of
>features and their values is given, just because the syntax will
>look so similar.  Anything we can do to make that as clear as possible
>will be useful.

I think we agree, but just to double-check, I'd re-phrase part of the above:

# There is a chance to confuse a URI that identifies a single feature and
# a URI that indicates a feature set constraint.

>> >... we also
>> >need to specify exactly what you get if you retrieve h.<URI>.
>> 
>> I think that what you get is a copy of the hashed feature expression.
>
>Yes, but we need to specify exactly how that is represented.  Remember
>that most hashes on files care about every bit of whitespace and every
>control character; if we don't specify the representation very well,
>we will end up with conflicting hashes on equivalent feature expressions.

Clearly we must be clear about this.  I see two approaches:
(a) canonicalize the feature expression in some way (normalize whitespace,
etc.)
(b) simply treat the feature expression as a literal string, define
carefully how the hash is computed over the string, and be sure that any
dereferencing mechanism preserves the string byte-for-byte.

There is also the issue that Martin raised, which implies a more aggressive
form of canonicalization (e.g. reduce to Disjuntive normal form, and sort
in some defined way).  I'm not sure we'd want to go that far.

>> >...  Refer to the hash with a
>> >URI that contains the disaggregated form, and the parties will
>> >sometimes be able to retrieve the disaggregated forms.
>> 
>> That would be the above case, omitting the WHERE clause.
>
>Only if you assume all the steps which are involved in retrieving the
>dereferenced/disaggregated forms.

I think I'm only assuming the existence of steps that can perform the
dereferencing.  IMO, it doesn't matter to the result what those steps are,
as long as the correct disaggregation is delivered.

>...  This is why I don't agree that the
>mechanism of dereferencing/disaggregation can be dealt with *solely*
>on a protocol by protocol basis. Remember that one of the goals of
>this system is that feature information presented in it ought to be
>usable across protocols and through protocol gateways.  If we leave
>the dereferencing/disaggregation step totally within the purview of a
>specific protocol, the http-based ones may well use
>(h.http://www.foo.com/featurepredicates.txt=<HASH>) where directory
>services based systems might use
>(h.ldap://ldap.server.com/dn=featurepredicates,o=foo,c=us)=<HASH>)
>
>As long as the <HASH> is the same, we don't have a problem. If a
>lookup is needed and the "wrong" url scheme is used, the match fails
>for lack of information.  Inband error reporting and retrieval may fix
>that in some cases, but it remains a concern.  

I think this is the redundant vocabulary problem:  if two feature tags
describe the same feature, how do you know they match?

I also think this illustrates a pitfall of using URLs as identifiers.
Bceause it's a URL it is possible to assume that the only way to resolve it
is to employ the protocol indicated by the URL sheme.  While that is one
reasonable way, I don't agree that it's the only way.

>> I don't think the method here is a one size fits all type of solution.  Any
>> given application would need to indicate an appropriate method.  For
>> example:  in WWW, retreive the resource indicated by the URI;   in e-mail
>> use the tag in a directory search or RESCAP (aka MAILCAP) resolution.
>
>I don't want to be tarred with a "one-size" fits all brush here; I
>want, instead, to say we have to make all the suits out of the same
>materials.  That may mean that we say, for example, directory lookups
>for these should be able to key on the <HASH>, rather than only on the
><h.URI>, but we don't specify what directory we use.  

To avoid debating this as a "religious" issue, can we agree to keep issues
of representation and resolution as separate as possible?

For example, if I can demonstrate that a given expression is meaningful in
the absence of any specific resolution mechanism, then it be allowed to
stand alone.  Or if you can show that the meaning of an expression really
does depend on (aspects of) a resolution mechanism, then the needed
resoloution elements are incorporated into the definition of meaning.

This does not preclude addressing some resolution mechanism issues as
separate items is that is desired, but I suspect that you'd want to stay
away from that.

>> I'd be happy to have a go at the (h.<URI2>="<hash>") proposal, if that
>> doesn't pre-empt anything that Bill is planning.  I would be more
>> comfortable if we had some consensus on scenarios and goals so that it can
>> be seen to address the perceived problem.
>> 
>> #g
>
>Any concrete proposal would be good, and two may well be better at this
>early stage.

OK, I'll add it to my todo list.  When's the Minneapolis I-D deadline?
I'll try to beat that by a week or two.

#g

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