[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[paf@bunyip.com: Re: SDSI syntax]

Simon raises the issue of query syntax (copy below).  SDSI uses
a ``template'' format, so that Simon's example object:

(b: (c: bar)
    (d: fratz))

would satisfy the SDSI search template:

     ( Template: ( b: (d: fratz ) ) )

The details of the template matching rules are given in the paper:
     http://theory.lcs.mit.edu/~rivest/sdsi.ps (or .tex) Basically,
give the object or attribute type and its required parameters,

	Ron Rivest

Return-Path: <owner-spki@c2.org>
X-Sender: m-3329@mailbox.swip.net
Mime-Version: 1.0
Date: Tue, 30 Apr 1996 06:20:31 +0200
To: Simon Spero <ses@tipper.oit.unc.edu>,
        Ron Rivest <rivest@theory.lcs.mit.edu>
From: paf@bunyip.com (Patrik Faltstrom)
Subject: Re: SDSI syntax
Cc: spki@c2.org, leslie@bunyip.com
Sender: owner-spki@c2.org
Precedence: bulk

At 15.59 96-04-29, Simon Spero wrote:
>Whois++ (and in general all RFC822 derived formats) are basically flat.

What we did in Whois++ was to define that:

1) One attribute name can occur several times (as in RFC-822)
2) The order of the attributes are significant (which is not the case
   in RFC-822)

By using this grouping functionality in Whois++ one can simulate
"nesting", and we choose this because of implementation constraints.

Keeping track of arbitrary order and multiple attribute names can
be hard enough for a server, but keeping track of real object oriented
structures are a totally different thing. Especially when you start
searching in the object.

Say that you have

(a: foo)
(b: (c: bar)
    (d: fratz))

Should you be able to search on "d=fratz", "b.d=fratz" ?

In Whois++ you can express this as

a: foo
start: b
c: bar
d: fratz
end: b

I.e. by including "fake" attribute values, the client can parse this
and recreate the nesting. The query syntax becomes simpler, and that
_is_ sometimes a good thing (tm).