Re: Questions about HTTP/V1.0 doc dated 14-Jul-93

fwilliam@ccs.carleton.ca (Fred Williams)
From: fwilliam@ccs.carleton.ca (Fred Williams)
Message-id: <9308170058.AA05453@superior.YP.nobel>
Subject: Re: Questions about HTTP/V1.0 doc dated 14-Jul-93
To: dsr@hplb.hpl.hp.com (Dave_Raggett)
Date: Mon, 16 Aug 93 20:58:46 EDT
Cc: www-talk@nxoc01.cern.ch
In-reply-to: <9308131639.AA00992@manuel.hpl.hp.com>; from "Dave_Raggett" at Aug 13, 93 5:39 pm
X-Mailer: ELM [version 2.3 PL11]
Status: RO
Dave_Raggett writes:
> 
> Fred Williams says:
> 
> > 3)  An earlier document on HTTP describes the TEXTSEARCH method to request a
> >     search to be done utilizing search information contained in the data
> >     section.  Since the data section is in MIME this would allow complex 
> >     searches to be done and searches done on information other than ASCII
> >     text. The latest document seems to degrade method TEXTSEARCH to only a
> >     server response to indicate that searching is possible.  One then uses
> >     the GET method ( ie ?xxx+yyy ... ) to perform the actual search.  This
> >     does now restrict the search capabilities to only ASCII and simple
> >     searches.(ie 'very' limited pattern matching and no boolean operators ).
> >     Is it now intended to keep TEXTSEARCH only as a response ( ie
> >     duplicating [ISINDEX] functionality) or to return its functionality as
> >     a request method.
> 
> I am very interested in clarifying the spec for search strings as I see it
> as being an enabler for the forms that can be specified with HTML+.
> 
> In an earlier message I suggested taking advantage of the special characters
> permitted in search strings to specify attribute value pairs and boolean
> operators. (see http://info.cern.ch/hypertext/WWW/Addressing/BNF.html)
> What we need now is some guidelines for this to be included in the HTRQ spec.
> 
> The following lists the special chars along with suggested roles:
> 
>         $       Prefix for variable names
>         _       Used as ordinary char in identifiers
>         @       Infix operator as in attribute@value
>         !       Logical negation
>         %       For escaping other characters e.g. %20 for the space char.
>         ^       Logical disjunction
>         &       Logical conjunction
>         *       Not sure what to use this for ...
>         (       Left bracket for grouping things
>         )       Right bracket for grouping things
>         .       Decimal point in numbers or period in text.
> 
> It would be very useful to also allow:
> 
>         ,       minor separator
>         ;       major separator
> 
> These are needed for sending lists of points, as in the ismap mechanism for
> IMG. Are there any problems in extending the definition of "xalpha" Tim?
> 
> Any comments?
> 
> Dave Raggett
> 
          This still does not allow for questions like `is
this image part of another' or `is this audio segment contained in
this document'.  Now this may seem that these requests
may be a little out of the ordinary however I feel that the definition
of HTTP/V1.0 should not restrict these types of searches.  If, as
suggested, the TEXTSEARCH ( which should be renamed SEARCH ) is
implemented as a request method, utilizing the data portion of the
request to define the search, there would be no restrictions on the
searching capabilities of HTTP/V1.0.  It would be entirely up to the
client and server capabilities.

Fred Williams
fwilliam@ccs.carleton.ca