Re: Whois++ constraints

[Peter Deutsch <[e-mail]>]

g'day Mark,

Welcome back. I trust it wasn't too gruelling a flight
across the pond...

[ You wrote: ]

> Can we please agree to change the syntax for the constaints before our
> respective servers are released.
> 
> I would suggest the following syntax
> 
> <keyword> [ "=" <value> ] { "," <keyword> [ "=" <value> ] }

I see no problems with this as the general structure of
global constraints, although we'll obviously have to watch
things to be sure that the BNF allows for the various
legal constaints and options. One example that comes to
mind is that I've been assuming so far that we can allow
only one of the possible output format specifiers per
query. Ditto for search type and so on.

Of course, in these particular examples, we may be able to
punt the problem. I'm actually wordsmithing the document
right now and I've added the following section to the
overview part in response to your question about how to
handle muliple template specifier terms, and multiple
terms in general:


# The WHOIS++ Search Selection Mechanism
# ---------------------------------------
# 
# The WHOIS++ search mechanism is intended to be extremely simple.  A search
# command consists of one or more search terms, with an optional set of 
# global constraints and option specifiers that modify or control the search.
# Search terms allow the user to specify template type, attribute, value
# or handle that any record returns must satisfy.
# 
# A WHOIS++ database may be seen as a single rolodex-like collection of
# typed records.  Each term specifies a further constraint that the
# selected set of output records must satisfy. Each term may thus be
# thought of as performing a subtractive selection, in the sense that any
# record that does not fulfill the term is discarded from the result set.
# There is currently no provision for Boolean searches (other than an
# implied AND between search terms) or other elaborate more search
# mechanisms in WHOIS++.
# 
# The simple, subtractive nature of WHOIS++ queries, and the lack of
# Boolean search operations, could lead to possible ambiguities if
# certain combinations of search terms were allowed. For example, if the
# user were to specify more than one template type for a given search
# either no matches could occur (since it is implicit that no record can
# have more than one template type associated with it) or a logical OR
# operation would have to be inferred.
# 
# To handle such cases, the second and all subsequent terms are to be
# discarded and a suitable warning returned along with the results of
# the search.  This occurs when either multiple template types, or
# multiple handles are specified in a search.

Thus, we _could_ handle such things as multiple output
format specifiers the same way I've proposed handling
multiple template or handle specifiers - accept the first,
then toast the rest, then run the query.

The problem with this approach for output format is that if
somebody goofs, it's conceivable that they end up
specifying (and thus receiving) lots of unwanted full
record search results (which when we have MIME output
sound and video is going to be a bear.. :-(
Because of this, in the case of output format it may be
better if we were to take a more conservative approach and
simply declare an error and bail out.

This raises the whole spectre of fully specifying error
conditions (eeew!). At Alan's suggestion, I've printed out
RFC 959 (the ftp spec) to consider their various error 
messages for inspiration. I like the general scheme of
classifying errors by type and severity. I'll post more on
this once I've had to chance to study this more closely.

So, Mark, on a first reading I see no problem with what
you're proposing and it seems to fit in with the growing
power of the general constraints and options features
nicely (of course, it's 2:30 here and I'm getting punchy.
I may disagree with myself tomorrow, but I doubt it).


> Having "," as a separator allows an implementation that doesn't support
> all the options to easily skip over constraints it doesn't understand
> by just skipping up to the next ",".

Sure does. Don't know why I didn't put that in on the
first pass.  Probably because it, too, was written at 3am.
Or maybe because at that point the only constraints we had
were search type and response type (and maybe MAXHITS).
Now they're taking shape your approach seems to make a lot
of sense.

> I would also like to transform the constraints "full", "handle",
> "abridged", and "summary" into "format=(full|handle|abridged|summary)".
> This will allow us to easily add formats, such as mime, later on
> without extending the keywords into infinity.

I definitely agree. Consider the doc revised on this (unless
someone else squeals RSN??).

FYI, I've finished most of the revision of the first part
(the easy bit since this is all exposition). I've done
some basic wordsmithing (eg: I've added the standard
INTERNET DRAFT intro, a contents page, an ACKNOWLEDGEMENTS
section, revised the wording throughout the first part,
etc.) The doc really is starting to take shape.

I still have a lot of detailed grunge work to do in paret
II, to finish adding the options stuff, redoing the output
format stuff to know about MIME, adding the new error and
warning message stuff and cleaning up the BNF (which just
never got done, and is now obviously changed considerably
after Columbus). There's obviously still lots to do but
I'll post a new draft as soon as I have something.
Meanwhile, please keep posting comments and feedback...

It's late enough here now that I'm going to call it a
night. As more issues come up I'll post (unless Mark beats
me to it?? :-)


				- peterd


-- 
------------------------------------------------------------------------------
Peter Deutsch,                                       [e-mail]
President,                                        [phone]  (phone)
Bunyip Information Systems Inc.                    [phone]  (fax)

  "any sufficiently advanced magic is indistinguishable from technology"
           (- with apologies to Arthur C. Clarke, who almost got it right...)
------------------------------------------------------------------------------